Tile Signaling In Video Coding

ABSTRACT

A video coding mechanism is disclosed. The mechanism includes receiving a bitstream including image data divided into one or more slices. The one or more slices are further divided into one or more tiles. The mechanism further includes determining that a first slice contains a single tile based on a first flag. The mechanism further includes decoding the first slice to generate a reconstructed image.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of International ApplicationNo. PCT/US2019/051152, filed Sep. 13, 2019 by Ye-Kui Wang, et. al., andtitled “Tile Signaling In Video Coding,” which claims the benefit ofU.S. Provisional Patent Application No. 62/731,696, filed Sep. 14, 2018by Ye-Kui Wang, et. al., and titled “Slicing and Tiling In VideoCoding,” which are hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure is generally related to video coding, and isspecifically related to partitioning images into slices, tiles, andcoding tree units (CTUs) to support increased compression in videocoding.

BACKGROUND

The amount of video data needed to depict even a relatively short videocan be substantial, which may result in difficulties when the data is tobe streamed or otherwise communicated across a communications networkwith limited bandwidth capacity. Thus, video data is generallycompressed before being communicated across modem day telecommunicationsnetworks. The size of a video could also be an issue when the video isstored on a storage device because memory resources may be limited.Video compression devices often use software and/or hardware at thesource to code the video data prior to transmission or storage, therebydecreasing the quantity of data needed to represent digital videoimages. The compressed data is then received at the destination by avideo decompression device that decodes the video data. With limitednetwork resources and ever increasing demands of higher video quality,improved compression and decompression techniques that improvecompression ratio with little to no sacrifice in image quality aredesirable.

SUMMARY

In an embodiment, the disclosure includes a method implemented in adecoder. The method comprises receiving, by a receiver of the decoder, abitstream including image data divided into one or more slices. The oneor more slices are further divided into one or more tiles. The methodfurther comprises determining, by a processor of the decoder, that afirst slice contains a single tile based on a first flag. The methodfurther comprises decoding, by the processor, the first slice togenerate a reconstructed image. The present disclosure includes a flagthat indicates when a slice contains only one tile. The decodergenerally performs several operations to determine the tiles in a slice,the IDs of those tiles, and associated entry point offsets so that thetiles can be decoded. These steps can be omitted and the associated dataomitted from the bitstream when the slice contains only one tile. Thecase that a slice carries a single tile may occur with some frequency.Accordingly, omitting unnecessary multi-tile related computations when asingle tile is present may significantly reduce computation resourceusage at the decoder. Further, omitting data supporting such multi-tilerelated computations from the bitstream may condense the bitstream,which may decrease network communication resource usage as well asmemory resource usage at both the encoder and decoder.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the first flag is asingle_tile_in_slice_flag set to one to indicate that there is only onetile in the first slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the first flag is coded in a slice headerassociated with the first slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein decoding the first slice includes omittinga search for a bottom right tile identifier (ID) for the first slicebased on the determination that the first slice contains the singletile.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein decoding the first slice includes omittinga search for entry point offsets associated with tiles for the firstslice based on the determination that the first slice contains thesingle tile.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, further comprising determining, by the processor,that a first picture contains the single tile based on a second flag.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the second flag is asingle_tile_in_pic_flag set in a picture parameter set associated withthe first picture.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein decoding the first slice is performed aspart of decoding the first picture to generate the reconstructed image,and wherein decoding the first picture includes omitting a determinationof tile rows and tile columns for the first picture based on thedetermination that the first picture contains the single tile.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, further comprising forwarding, by the processor,the reconstructed image toward a display as part of a reconstructedvideo sequence.

In an embodiment, the disclosure includes a method implemented in anencoder. The method comprises partitioning, by a processor of theencoder, a first image into one or more slices. The one or more slicesare further partitioned into one or more tiles. The method furthercomprises determining, by the processor, that a first slice of the firstimage contains a single tile after partitioning. The method furthercomprises encoding, by the processor, a first flag to indicate that thefirst slice contains the single tile. The method further comprisesencoding, by the processor, the first slice into a bitstream. The methodfurther comprises transmitting, by a transmitter of the encoder, thebitstream containing the first flag to support decoding the first slice.The present disclosure includes a flag that indicates when a slicecontains only one tile. The decoder generally performs severaloperations to determine the tiles in a slice, the IDs of those tiles,and associated entry point offsets so that the tiles can be decoded.These steps can be omitted and the associated data omitted from thebitstream when the slice contains only one tile. The case that a slicecarries a single tile may occur with some frequency. Accordingly,omitting unnecessary multi-tile related computations when a single tileis present may significantly reduce computation resource usage at thedecoder. Further, omitting data supporting such multi-tile relatedcomputations from the bitstream may condense the bitstream, which maydecrease network communication resource usage as well as memory resourceusage at both the encoder and decoder.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the first flag is asingle_tile_in_slice_flag set to one to indicate that there is only onetile in the first slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the first flag is encoded in a slice headerassociated with the first slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein a bottom right tile ID for the first sliceis omitted from the bitstream based on the determination that the firstslice contains the single tile.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein entry point offsets associated with tilesfor the first slice are omitted from the bitstream based on thedetermination that the first slice contains the single tile.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, further comprising determining, by the processor,that the first image contains the single tile after partitioning, andencoding, by the processor, a single_tile_in_pic_flag in a pictureparameter set associated with the first image to indicate that the firstimage contains the single tile.

In an embodiment, the disclosure includes a video coding devicecomprising a processor, a receiver coupled to the processor, and atransmitter coupled to the processor, the processor, receiver, andtransmitter configured to perform the method of any of the precedingaspects.

In an embodiment, the disclosure includes a non-transitory computerreadable medium comprising a computer program product for use by a videocoding device, the computer program product comprising computerexecutable instructions stored on the non-transitory computer readablemedium such that when executed by a processor cause the video codingdevice to perform the method of any of the preceding aspects.

In an embodiment, the disclosure includes a decoder comprising areceiving means for receiving a bitstream including image data dividedinto one or more slices. The one or more slices are further divided intoand one or more tiles. The decoder further comprises a determining meansfor determining that a first slice contains a single tile based on afirst flag. The decoder further comprises a decoding means for decodingthe first slice to generate a reconstructed image.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the encoder is further configured toperform the method of any of the preceding aspects.

In an embodiment, the disclosure includes an encoder comprises apartitioning means for partitioning a first image into one or moreslices. The one or more slices are further partitioned into one or moretiles. The encoder further comprises a determining means for determiningthat a first slice contains a single tile after partitioning. Theencoder further comprises an encoding means for encoding a first flag toindicate that the first slice contains the single tile, and encoding thefirst slice into a bitstream. The encoder further comprises atransmitting means for transmitting the bitstream containing the firstflag to support decoding the first slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the encoder is further configured toperform the method of any of the preceding aspects.

For the purpose of clarity, any one of the foregoing embodiments may becombined with any one or more of the other foregoing embodiments tocreate a new embodiment within the scope of the present disclosure.

These and other features will be more clearly understood from thefollowing detailed description taken in conjunction with theaccompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a flowchart of an example method of coding a video signal.

FIG. 2 is a schematic diagram of an example coding and decoding (codec)system for video coding.

FIG. 3 is a schematic diagram illustrating an example video encoder.

FIG. 4 is a schematic diagram illustrating an example video decoder.

FIG. 5 is a schematic diagram illustrating an example bitstreamcontaining an encoded video sequence.

FIG. 6 is a schematic diagram illustrating an example image partitionedfor coding.

FIG. 7 is a schematic diagram of an example image with a slicecontaining a single tile.

FIG. 8 is a schematic diagram of an example video coding device.

FIG. 9 is a flowchart of an example method of encoding an image with aslice containing a single tile into a bitstream.

FIG. 10 is a flowchart of an example method of decoding an image with aslice containing a single tile from a bitstream.

FIG. 11 is a schematic diagram of an example system for coding an imagecontaining a single slice and/or tile in a bitstream.

DETAILED DESCRIPTION

It should be understood at the outset that although an illustrativeimplementation of one or more embodiments are provided below, thedisclosed systems and/or methods may be implemented using any number oftechniques, whether currently known or in existence. The disclosureshould in no way be limited to the illustrative implementations,drawings, and techniques illustrated below, including the exemplarydesigns and implementations illustrated and described herein, but may bemodified within the scope of the appended claims along with their fullscope of equivalents.

Many video compression techniques can be employed to reduce the size ofvideo files with minimal loss of data. For example, video compressiontechniques can include performing spatial (e.g., intra-picture)prediction and/or temporal (e.g., inter-picture) prediction to reduce orremove data redundancy in video sequences. For block-based video coding,a video slice (e.g., a video picture or a portion of a video picture)may be partitioned into video blocks, which may also be referred to astreeblocks, coding tree blocks (CTBs), coding tree units (CTUs), codingunits (CUs), and/or coding nodes. Video blocks in an intra-coded (I)slice of a picture are coded using spatial prediction with respect toreference samples in neighboring blocks in the same picture. Videoblocks in an inter-coded unidirectional prediction (P) or bidirectionalprediction (B) slice of a picture may be coded by employing spatialprediction with respect to reference samples in neighboring blocks inthe same picture or temporal prediction with respect to referencesamples in other reference pictures. Pictures may be referred to asframes and/or images, and reference pictures may be referred to asreference frames and/or reference images. Spatial or temporal predictionresults in a predictive block representing an image block. Residual datarepresents pixel differences between the original image block and thepredictive block. Accordingly, an inter-coded block is encoded accordingto a motion vector that points to a block of reference samples formingthe predictive block and the residual data indicating the differencebetween the coded block and the predictive block. An intra-coded blockis encoded according to an intra-coding mode and the residual data. Forfurther compression, the residual data may be transformed from the pixeldomain to a transform domain. These result in residual transformcoefficients, which may be quantized. The quantized transformcoefficients may initially be arranged in a two-dimensional array. Thequantized transform coefficients may be scanned in order to produce aone-dimensional vector of transform coefficients. Entropy coding may beapplied to achieve even more compression. Such video compressiontechniques are discussed in greater detail below.

To ensure an encoded video can be accurately decoded, video is encodedand decoded according to corresponding video coding standards. Videocoding standards include International Telecommunication Union (ITU)Standardization Sector (ITU-T) H.261, International Organization forStandardization/International Electrotechnical Commission (ISO/IEC)Motion Picture Experts Group (MPEG)-1 Part 2, ITU-T H.262 or ISO/IECMPEG-2 Part 2, ITU-T H.263, ISO/IEC MPEG-4 Part 2, Advanced Video Coding(AVC), also known as ITU-T H.264 or ISO/IEC MPEG-4 Part 10, and HighEfficiency Video Coding (HEVC), also known as ITU-T H.265 or MPEG-H Part2. AVC includes extensions such as Scalable Video Coding (SVC),Multiview Video Coding (MVC) and Multiview Video Coding plus Depth(MVC+D), and three dimensional (3D) AVC (3D-AVC). HEVC includesextensions such as Scalable HEVC (SHVC), Multiview HEVC (MV-HEVC), and3D HEVC (3D-HEVC). The joint video experts team (JVET) of ITU-T andISO/IEC has begun developing a video coding standard referred to asVersatile Video Coding (VVC). VVC is included in a Working Draft (WD),which includes JVET-K1001-v4 and JVET-K1002-v1.

In order to code a video image, the image is first partitioned, and thepartitions are coded into a bitstream. Various picture partitioningschemes are available. For example, an image can be partitioned intoregular slices, dependent slices, tiles, and/or according to WavefrontParallel Processing (WPP). For simplicity, HEVC restricts encoders sothat only regular slices, dependent slices, tiles, WPP, and combinationsthereof can be used when partitioning a slice into groups of CTBs forvideo coding. Such partitioning can be applied to support MaximumTransfer Unit (MTU) size matching, parallel processing, and reducedend-to-end delay. MTU denotes the maximum amount of data that can betransmitted in a single packet. If a packet payload is in excess of theMTU, that payload is split into two packets through a process calledfragmentation.

A regular slice, also referred to simply as a slice, is a partitionedportion of an image that can be reconstructed independently from otherregular slices within the same picture, notwithstanding someinterdependencies due to loop filtering operations. Each regular sliceis encapsulated in its own Network Abstraction Layer (NAL) unit fortransmission. Further, in-picture prediction (intra sample prediction,motion information prediction, coding mode prediction) and entropycoding dependency across slice boundaries may be disabled to supportindependent reconstruction. Such independent reconstruction supportsparallelization. For example, regular slice based parallelizationemploys minimal inter-processor or inter-core communication. However, aseach regular slice is independent, each slice is associated with aseparate slice header. The use of regular slices can incur a substantialcoding overhead due to the bit cost of the slice header for each sliceand due to the lack of prediction across the slice boundaries. Further,regular slices may be employed to support matching for MTU sizerequirements. Specifically, as a regular slice is encapsulated in aseparate NAL unit and can be independently coded, each regular sliceshould be smaller than the MTU in MTU schemes to avoid breaking theslice into multiple packets. As such, the goal of parallelization andthe goal of MTU size matching may place contradicting demands to a slicelayout in a picture.

Dependent slices are similar to regular slices, but have shortened sliceheaders and allow partitioning of the image treeblock boundaries withoutbreaking in-picture prediction. Accordingly, dependent slices allow aregular slice to be fragmented into multiple NAL units, which providesreduced end-to-end delay by allowing a part of a regular slice to besent out before the encoding of the entire regular slice is complete.

A tile is a partitioned portion of an image created by horizontal andvertical boundaries that create columns and rows of tiles. Tiles may becoded in raster scan order (right to left and top to bottom). The scanorder of CTBs is local within a tile. Accordingly, CTBs in a first tileare coded in raster scan order, before proceeding to the CTBs in thenext tile. Similar to regular slices, tiles break in-picture predictiondependencies as well as entropy decoding dependencies. However, tilesmay not be included into individual NAL units, and hence tiles may notbe used for MTU size matching. Each tile can be processed by oneprocessor/core, and the inter-processor/inter-core communicationemployed for in-picture prediction between processing units decodingneighboring tiles may be limited to conveying a shared slice header(when adjacent tiles are in the same slice), and performing loopfiltering related sharing of reconstructed samples and metadata. Whenmore than one tile is included in a slice, the entry point byte offsetfor each tile other than the first entry point offset in the slice maybe signaled in the slice header. For each slice and tile, at least oneof the following conditions should be fulfilled: 1) all coded treeblocksin a slice belong to the same tile; and 2) all coded treeblocks in atile belong to the same slice.

In WPP, the image is partitioned into single rows of CTBs. Entropydecoding and prediction mechanisms may use data from CTBs in other rows.Parallel processing is made possible through parallel decoding of CTBrows. For example, a current row may be decoded in parallel with apreceding row. However, decoding of the current row is delayed from thedecoding process of the preceding rows by two CTBs. This delay ensuresthat data related to the CTB above and the CTB above and to the right ofthe current CTB in the current row is available before the current CTBis coded. This approach appears as a wavefront when representedgraphically. This staggered start allows for parallelization with up toas many processors/cores as the image contains CTB rows. Becausein-picture prediction between neighboring treeblock rows within apicture is permitted, the inter-processor/inter-core communication toenable in-picture prediction can be substantial. The WPP partitioningdoes consider NAL unit sizes. Hence, WPP does not support MTU sizematching. However, regular slices can be used in conjunction with WPP,with certain coding overhead, to implement MTU size matching as desired.

Tiles may also include motion constrained tile sets. A motionconstrained tile set (MCTS) is a tile set designed such that associatedmotion vectors are restricted to point to full-sample locations insidethe MCTS and to fractional-sample locations that require onlyfull-sample locations inside the MCTS for interpolation. Further, theusage of motion vector candidates for temporal motion vector predictionderived from blocks outside the MCTS is disallowed. This way, each MCTSmay be independently decoded without the existence of tiles not includedin the MCTS. Temporal MCTSs supplemental enhancement information (SEI)messages may be used to indicate the existence of MCTSs in the bitstreamand signal the MCTSs. The MCTSs SEI message provides supplementalinformation that can be used in the MCTS sub-bitstream extraction(specified as part of the semantics of the SEI message) to generate aconforming bitstream for a MCTS. The information includes a number ofextraction information sets, each defining a number of MCTS sets andcontaining raw bytes sequence payload (RBSP) bytes of the replacementvideo parameter sets (VPSs), sequence parameter sets (SPSs), and pictureparameter sets (PPSs) to be used during the MCTS sub-bitstreamextraction process. When extracting a sub-bitstream according to theMCTS sub-bitstream extraction process, parameter sets (VPSs, SPSs, andPPSs) may be rewritten or replaced, and slice headers may updatedbecause one or all of the slice address related syntax elements(including first_slice_segment_in_pic_flag and slice_segment_address)may employ different values in the extracted sub-bitstream.

The preceding tiling and slicing mechanisms provide significantflexibility to support MTU size matching and parallel processing.However, MTU size matching has become less relevant due to the everincreasing speed and reliability of telecommunication networks. Forexample, one of the primary uses of MTU size matching is to supportdisplaying error-concealed pictures. An error-concealed picture is adecoded picture that is created from a transmitted coded picture whenthere is some data loss. Such data loss can include a loss of someslices of a coded picture or errors in reference pictures used by thecoded picture (e.g., the reference picture is also an error-concealedpicture). An error-concealed picture can be created by displaying thecorrect slices and estimating the erroneous slices, for example bycopying a slice corresponding to the erroneous slice from the previouspicture in the video sequence. Error-concealed pictures can be generatedwhen each slice is contained in a single NAL unit. However, if slicesare fragmented over multiple NAL units (e.g., no MTU size matching), theloss of one NAL unit can corrupt multiple slices. Generation oferror-concealed pictures is less relevant in modem network environmentsas packet loss is a much less common occurrence and because modemnetwork speeds allow the system to completely omit pictures with errorswithout causing significant video freezing as the delay between anerroneous picture and a following error-less picture is generally small.Further, the process for estimating the quality of an error-concealedpicture may be complicated, and hence simply omitting the erroneouspicture may be preferable. Consequently, video conversationalapplications, such as video conferencing and video telephony, and evenbroadcast applications generally forgo using error-concealed pictures.

As error-concealed pictures are less useful, MTU size matching is lessuseful. Further, continuing to support MTU size matching paradigms whenpartitioning may unnecessarily complicate coding systems and as well asuse waste bits that could otherwise be omitted to increase codingefficiency. In addition, some tiling schemes (e.g., MCTS) allowsub-pictures of a picture to be displayed. In order to display asub-picture, slices in a region of interest are displayed and otherslices are omitted. The region of interest may begin at a location otherthan the top left portion of the picture, and may therefore haveaddresses that are offset from the start of the picture by a variablevalue. In order to properly display the sub-image, a splicer may be usedto rewrite the slice header(s) for the region of interest to account forthis offset. A slicing and tiling scheme that did not require such sliceheader rewriting would be beneficial. In addition, tile boundaries maynot be treated as picture boundaries unless they are collocated withpicture boundaries. However, treating tile boundaries as pictureboundaries may increase coding efficiency in some cases due to thepadding of the boundaries and due to relaxing constraints related tomotion vectors that point to samples outside the boundaries in thereference pictures. Also, HEVC may employ a flag named end_of_slice_flagat the end of the coded data for each CTU to indicate whether the end ofthe slice has been reached. AVC employs this flag at the end of thecoded data for each macroblock (MB) for the same purpose. However,coding of this flag is unnecessary and a waste of bits when the lastCTU/MB is known through other mechanisms. The present disclosurepresents mechanisms to address these and other issues in the videocoding arts.

Disclosed herein are various mechanisms to increase the codingefficiency and reduce processing overhead associated with the slicingand tiling schemes discussed above. In an example, an image may bepartitioned to contain a single tile. A decoder may perform severaloperations to determine the tiles in a slice, the tile identifiers (IDs)of those tiles, and entry point offsets indicating the position of suchtiles in the bitstream. However, such computations are unnecessary whena slice contains a single tile. Accordingly, an encoder can encode aflag into the bitstream to indicate when a slice contains a single tile.This allows such operations to be omitted at the decoder. Further, thisallows corresponding data (e.g., some tile IDs, entry point offsets,etc.) to be omitted from the bitstream, which increases compressionand/or coding efficiency. As an example, such a flag may be implementedas a single_tile_in_slice_flag stored in a slice header associated withthe slice. Further, a decoder may determine slice boundaries based ontile IDs in some examples. However, this computation is unnecessary whenthe image contains a single tile. Accordingly, an encoder can encode aflag into the bitstream to indicate when an image contains a singletile. This allows such operations to be omitted at the decoder. Further,this allows corresponding data (e.g., some tile IDs, etc.) to be omittedfrom the bitstream, which increases compression and/or codingefficiency. As an example, such a flag may be implemented as asingle_tile_in_pic_flag stored in a picture parameter set (PPS)associated with the image/picture. These and other examples aredescribed in detail below.

FIG. 1 is a flowchart of an example operating method 100 of coding avideo signal. Specifically, a video signal is encoded at an encoder. Theencoding process compresses the video signal by employing variousmechanisms to reduce the video file size. A smaller file size allows thecompressed video file to be transmitted toward a user, while reducingassociated bandwidth overhead. The decoder then decodes the compressedvideo file to reconstruct the original video signal for display to anend user. The decoding process generally mirrors the encoding process toallow the decoder to consistently reconstruct the video signal.

At step 101, the video signal is input into the encoder. For example,the video signal may be an uncompressed video file stored in memory. Asanother example, the video file may be captured by a video capturedevice, such as a video camera, and encoded to support live streaming ofthe video. The video file may include both an audio component and avideo component. The video component contains a series of image framesthat, when viewed in a sequence, gives the visual impression of motion.The frames contain pixels that are expressed in terms of light, referredto herein as luma components (or luma samples), and color, which isreferred to as chroma components (or color samples). In some examples,the frames may also contain depth values to support three dimensionalviewing.

At step 103, the video is partitioned into blocks. Partitioning includessubdividing the pixels in each frame into square and/or rectangularblocks for compression. For example, in High Efficiency Video Coding(HEVC) (also known as H.265 and MPEG-H Part 2) the frame can first bedivided into coding tree units (CTUs), which are blocks of a predefinedsize (e.g., sixty-four pixels by sixty-four pixels). The CTUs containboth luma and chroma samples. Coding trees may be employed to divide theCTUs into blocks and then recursively subdivide the blocks untilconfigurations are achieved that support further encoding. For example,luma components of a frame may be subdivided until the individual blockscontain relatively homogenous lighting values. Further, chromacomponents of a frame may be subdivided until the individual blockscontain relatively homogenous color values. Accordingly, partitioningmechanisms vary depending on the content of the video frames.

At step 105, various compression mechanisms are employed to compress theimage blocks partitioned at step 103. For example, inter-predictionand/or intra-prediction may be employed. Inter-prediction is designed totake advantage of the fact that objects in a common scene tend to appearin successive frames. Accordingly, a block depicting an object in areference frame need not be repeatedly described in adjacent frames.Specifically, an object, such as a table, may remain in a constantposition over multiple frames. Hence the table is described once andadjacent frames can refer back to the reference frame. Pattern matchingmechanisms may be employed to match objects over multiple frames.Further, moving objects may be represented across multiple frames, forexample due to object movement or camera movement. As a particularexample, a video may show an automobile that moves across the screenover multiple frames. Motion vectors can be employed to describe suchmovement. A motion vector is a two-dimensional vector that provides anoffset from the coordinates of an object in a frame to the coordinatesof the object in a reference frame. As such, inter-prediction can encodean image block in a current frame as a set of motion vectors indicatingan offset from a corresponding block in a reference frame.

Intra-prediction encodes blocks in a common frame. Intra-predictiontakes advantage of the fact that luma and chroma components tend tocluster in a frame. For example, a patch of green in a portion of a treetends to be positioned adjacent to similar patches of green.Intra-prediction employs multiple directional prediction modes (e.g.,thirty-three in HEVC), a planar mode, and a direct current (DC) mode.The directional modes indicate that a current block is similar/the sameas samples of a neighbor block in a corresponding direction. Planar modeindicates that a series of blocks along a row/column (e.g., a plane) canbe interpolated based on neighbor blocks at the edges of the row. Planarmode, in effect, indicates a smooth transition of light/color across arow/column by employing a relatively constant slope in changing values.DC mode is employed for boundary smoothing and indicates that a block issimilar/the same as an average value associated with samples of all theneighbor blocks associated with the angular directions of thedirectional prediction modes. Accordingly, intra-prediction blocks canrepresent image blocks as various relational prediction mode valuesinstead of the actual values. Further, inter-prediction blocks canrepresent image blocks as motion vector values instead of the actualvalues. In either case, the prediction blocks may not exactly representthe image blocks in some cases. Any differences are stored in residualblocks. Transforms may be applied to the residual blocks to furthercompress the file.

At step 107, various filtering techniques may be applied. In HEVC, thefilters are applied according to an in-loop filtering scheme. The blockbased prediction discussed above may result in the creation of blockyimages at the decoder. Further, the block based prediction scheme mayencode a block and then reconstruct the encoded block for later use as areference block. The in-loop filtering scheme iteratively applies noisesuppression filters, de-blocking filters, adaptive loop filters, andsample adaptive offset (SAO) filters to the blocks/frames. These filtersmitigate such blocking artifacts so that the encoded file can beaccurately reconstructed. Further, these filters mitigate artifacts inthe reconstructed reference blocks so that artifacts are less likely tocreate additional artifacts in subsequent blocks that are encoded basedon the reconstructed reference blocks.

Once the video signal has been partitioned, compressed, and filtered,the resulting data is encoded in a bitstream at step 109. The bitstreamincludes the data discussed above as well as any signaling data desiredto support proper video signal reconstruction at the decoder. Forexample, such data may include partition data, prediction data, residualblocks, and various flags providing coding instructions to the decoder.The bitstream may be stored in memory for transmission toward a decoderupon request. The bitstream may also be broadcast and/or multicasttoward a plurality of decoders. The creation of the bitstream is aniterative process. Accordingly, steps 101, 103, 105, 107, and 109 mayoccur continuously and/or simultaneously over many frames and blocks.The order shown in FIG. 1 is presented for clarity and ease ofdiscussion, and is not intended to limit the video coding process to aparticular order.

The decoder receives the bitstream and begins the decoding process atstep 111. Specifically, the decoder employs an entropy decoding schemeto convert the bitstream into corresponding syntax and video data. Thedecoder employs the syntax data from the bitstream to determine thepartitions for the frames at step 111. The partitioning should match theresults of block partitioning at step 103. Entropy encoding/decoding asemployed in step 111 is now described. The encoder makes many choicesduring the compression process, such as selecting block partitioningschemes from several possible choices based on the spatial positioningof values in the input image(s). Signaling the exact choices may employa large number of bins. As used herein, a bin is a binary value that istreated as a variable (e.g., a bit value that may vary depending oncontext). Entropy coding allows the encoder to discard any options thatare clearly not viable for a particular case, leaving a set of allowableoptions. Each allowable option is then assigned a code word. The lengthof the code words is based on the number of allowable options (e.g., onebin for two options, two bins for three to four options, etc.) Theencoder then encodes the code word for the selected option. This schemereduces the size of the code words as the code words are as big asdesired to uniquely indicate a selection from a small sub-set ofallowable options as opposed to uniquely indicating the selection from apotentially large set of all possible options. The decoder then decodesthe selection by determining the set of allowable options in a similarmanner to the encoder. By determining the set of allowable options, thedecoder can read the code word and determine the selection made by theencoder.

At step 113, the decoder performs block decoding. Specifically, thedecoder employs reverse transforms to generate residual blocks. Then thedecoder employs the residual blocks and corresponding prediction blocksto reconstruct the image blocks according to the partitioning. Theprediction blocks may include both intra-prediction blocks andinter-prediction blocks as generated at the encoder at step 105. Thereconstructed image blocks are then positioned into frames of areconstructed video signal according to the partitioning data determinedat step 111. Syntax for step 113 may also be signaled in the bitstreamvia entropy coding as discussed above.

At step 115, filtering is performed on the frames of the reconstructedvideo signal in a manner similar to step 107 at the encoder. Forexample, noise suppression filters, de-blocking filters, adaptive loopfilters, and SAO filters may be applied to the frames to remove blockingartifacts. Once the frames are filtered, the video signal can be outputto a display at step 117 for viewing by an end user.

FIG. 2 is a schematic diagram of an example coding and decoding (codec)system 200 for video coding. Specifically, codec system 200 providesfunctionality to support the implementation of operating method 100.Codec system 200 is generalized to depict components employed in both anencoder and a decoder. Codec system 200 receives and partitions a videosignal as discussed with respect to steps 101 and 103 in operatingmethod 100, which results in a partitioned video signal 201. Codecsystem 200 then compresses the partitioned video signal 201 into a codedbitstream when acting as an encoder as discussed with respect to steps105, 107, and 109 in method 100. When acting as a decoder codec system200 generates an output video signal from the bitstream as discussedwith respect to steps 111, 113, 115, and 117 in operating method 100.The codec system 200 includes a general coder control component 211, atransform scaling and quantization component 213, an intra-pictureestimation component 215, an intra-picture prediction component 217, amotion compensation component 219, a motion estimation component 221, ascaling and inverse transform component 229, a filter control analysiscomponent 227, an in-loop filters component 225, a decoded picturebuffer component 223, and a header formatting and context adaptivebinary arithmetic coding (CABAC) component 231. Such components arecoupled as shown. In FIG. 2, black lines indicate movement of data to beencoded/decoded while dashed lines indicate movement of control datathat controls the operation of other components. The components of codecsystem 200 may all be present in the encoder. The decoder may include asubset of the components of codec system 200. For example, the decodermay include the intra-picture prediction component 217, the motioncompensation component 219, the scaling and inverse transform component229, the in-loop filters component 225, and the decoded picture buffercomponent 223. These components are now described.

The partitioned video signal 201 is a captured video sequence that hasbeen partitioned into blocks of pixels by a coding tree. A coding treeemploys various split modes to subdivide a block of pixels into smallerblocks of pixels. These blocks can then be further subdivided intosmaller blocks. The blocks may be referred to as nodes on the codingtree. Larger parent nodes are split into smaller child nodes. The numberof times a node is subdivided is referred to as the depth of thenode/coding tree. The divided blocks can be included in coding units(CUs) in some cases. For example, a CU can be a sub-portion of a CTUthat contains a luma block, red difference chroma (Cr) block(s), and ablue difference chroma (Cb) block(s) along with corresponding syntaxinstructions for the CU. The split modes may include a binary tree (BT),triple tree (TT), and a quad tree (QT) employed to partition a node intotwo, three, or four child nodes, respectively, of varying shapesdepending on the split modes employed. The partitioned video signal 201is forwarded to the general coder control component 211, the transformscaling and quantization component 213, the intra-picture estimationcomponent 215, the filter control analysis component 227, and the motionestimation component 221 for compression.

The general coder control component 211 is configured to make decisionsrelated to coding of the images of the video sequence into the bitstreamaccording to application constraints. For example, the general codercontrol component 211 manages optimization of bitrate/bitstream sizeversus reconstruction quality. Such decisions may be made based onstorage space/bandwidth availability and image resolution requests. Thegeneral coder control component 211 also manages buffer utilization inlight of transmission speed to mitigate buffer underrun and overrunissues. To manage these issues, the general coder control component 211manages partitioning, prediction, and filtering by the other components.For example, the general coder control component 211 may dynamicallyincrease compression complexity to increase resolution and increasebandwidth usage or decrease compression complexity to decreaseresolution and bandwidth usage. Hence, the general coder controlcomponent 211 controls the other components of codec system 200 tobalance video signal reconstruction quality with bit rate concerns. Thegeneral coder control component 211 creates control data, which controlsthe operation of the other components. The control data is alsoforwarded to the header formatting and CABAC component 231 to be encodedin the bitstream to signal parameters for decoding at the decoder.

The partitioned video signal 201 is also sent to the motion estimationcomponent 221 and the motion compensation component 219 forinter-prediction. A frame or slice of the partitioned video signal 201may be divided into multiple video blocks. Motion estimation component221 and the motion compensation component 219 perform inter-predictivecoding of the received video block relative to one or more blocks in oneor more reference frames to provide temporal prediction. Codec system200 may perform multiple coding passes, e.g., to select an appropriatecoding mode for each block of video data.

Motion estimation component 221 and motion compensation component 219may be highly integrated, but are illustrated separately for conceptualpurposes. Motion estimation, performed by motion estimation component221, is the process of generating motion vectors, which estimate motionfor video blocks. A motion vector, for example, may indicate thedisplacement of a coded object relative to a predictive block. Apredictive block is a block that is found to closely match the block tobe coded, in terms of pixel difference. A predictive block may also bereferred to as a reference block. Such pixel difference may bedetermined by sum of absolute difference (SAD), sum of square difference(SSD), or other difference metrics. HEVC employs several coded objectsincluding a CTU, coding tree blocks (CTBs), and CUs. For example, a CTUcan be divided into CTBs, which can then be divided into CBs forinclusion in CUs. A CU can be encoded as a prediction unit (PU)containing prediction data and/or a transform unit (TU) containingtransformed residual data for the CU. The motion estimation component221 generates motion vectors, PUs, and TUs by using a rate-distortionanalysis as part of a rate distortion optimization process. For example,the motion estimation component 221 may determine multiple referenceblocks, multiple motion vectors, etc. for a current block/frame, and mayselect the reference blocks, motion vectors, etc. having the bestrate-distortion characteristics. The best rate-distortioncharacteristics balance both quality of video reconstruction (e.g.,amount of data loss by compression) with coding efficiency (e.g., sizeof the final encoding).

In some examples, codec system 200 may calculate values for sub-integerpixel positions of reference pictures stored in decoded picture buffercomponent 223. For example, video codec system 200 may interpolatevalues of one-quarter pixel positions, one-eighth pixel positions, orother fractional pixel positions of the reference picture. Therefore,motion estimation component 221 may perform a motion search relative tothe full pixel positions and fractional pixel positions and output amotion vector with fractional pixel precision. The motion estimationcomponent 221 calculates a motion vector for a PU of a video block in aninter-coded slice by comparing the position of the PU to the position ofa predictive block of a reference picture. Motion estimation component221 outputs the calculated motion vector as motion data to headerformatting and CABAC component 231 for encoding and motion to the motioncompensation component 219.

Motion compensation, performed by motion compensation component 219, mayinvolve fetching or generating the predictive block based on the motionvector determined by motion estimation component 221. Again, motionestimation component 221 and motion compensation component 219 may befunctionally integrated, in some examples. Upon receiving the motionvector for the PU of the current video block, motion compensationcomponent 219 may locate the predictive block to which the motion vectorpoints. A residual video block is then formed by subtracting pixelvalues of the predictive block from the pixel values of the currentvideo block being coded, forming pixel difference values. In general,motion estimation component 221 performs motion estimation relative toluma components, and motion compensation component 219 uses motionvectors calculated based on the luma components for both chromacomponents and luma components. The predictive block and residual blockare forwarded to transform scaling and quantization component 213.

The partitioned video signal 201 is also sent to intra-pictureestimation component 215 and intra-picture prediction component 217. Aswith motion estimation component 221 and motion compensation component219, intra-picture estimation component 215 and intra-picture predictioncomponent 217 may be highly integrated, but are illustrated separatelyfor conceptual purposes. The intra-picture estimation component 215 andintra-picture prediction component 217 intra-predict a current blockrelative to blocks in a current frame, as an alternative to theinter-prediction performed by motion estimation component 221 and motioncompensation component 219 between frames, as described above. Inparticular, the intra-picture estimation component 215 determines anintra-prediction mode to use to encode a current block. In someexamples, intra-picture estimation component 215 selects an appropriateintra-prediction mode to encode a current block from multiple testedintra-prediction modes. The selected intra-prediction modes are thenforwarded to the header formatting and CABAC component 231 for encoding.

For example, the intra-picture estimation component 215 calculatesrate-distortion values using a rate-distortion analysis for the varioustested intra-prediction modes, and selects the intra-prediction modehaving the best rate-distortion characteristics among the tested modes.Rate-distortion analysis generally determines an amount of distortion(or error) between an encoded block and an original unencoded block thatwas encoded to produce the encoded block, as well as a bitrate (e.g., anumber of bits) used to produce the encoded block. The intra-pictureestimation component 215 calculates ratios from the distortions andrates for the various encoded blocks to determine which intra-predictionmode exhibits the best rate-distortion value for the block. In addition,intra-picture estimation component 215 may be configured to code depthblocks of a depth map using a depth modeling mode (DMM) based onrate-distortion optimization (RDO).

The intra-picture prediction component 217 may generate a residual blockfrom the predictive block based on the selected intra-prediction modesdetermined by intra-picture estimation component 215 when implemented onan encoder or read the residual block from the bitstream whenimplemented on a decoder. The residual block includes the difference invalues between the predictive block and the original block, representedas a matrix. The residual block is then forwarded to the transformscaling and quantization component 213. The intra-picture estimationcomponent 215 and the intra-picture prediction component 217 may operateon both luma and chroma components.

The transform scaling and quantization component 213 is configured tofurther compress the residual block. The transform scaling andquantization component 213 applies a transform, such as a discretecosine transform (DCT), a discrete sine transform (DST), or aconceptually similar transform, to the residual block, producing a videoblock comprising residual transform coefficient values. Wavelettransforms, integer transforms, sub-band transforms or other types oftransforms could also be used. The transform may convert the residualinformation from a pixel value domain to a transform domain, such as afrequency domain. The transform scaling and quantization component 213is also configured to scale the transformed residual information, forexample based on frequency. Such scaling involves applying a scalefactor to the residual information so that different frequencyinformation is quantized at different granularities, which may affectfinal visual quality of the reconstructed video. The transform scalingand quantization component 213 is also configured to quantize thetransform coefficients to further reduce bit rate. The quantizationprocess may reduce the bit depth associated with some or all of thecoefficients. The degree of quantization may be modified by adjusting aquantization parameter. In some examples, the transform scaling andquantization component 213 may then perform a scan of the matrixincluding the quantized transform coefficients. The quantized transformcoefficients are forwarded to the header formatting and CABAC component231 to be encoded in the bitstream.

The scaling and inverse transform component 229 applies a reverseoperation of the transform scaling and quantization component 213 tosupport motion estimation. The scaling and inverse transform component229 applies inverse scaling, transformation, and/or quantization toreconstruct the residual block in the pixel domain, e.g., for later useas a reference block which may become a predictive block for anothercurrent block. The motion estimation component 221 and/or motioncompensation component 219 may calculate a reference block by adding theresidual block back to a corresponding predictive block for use inmotion estimation of a later block/frame. Filters are applied to thereconstructed reference blocks to mitigate artifacts created duringscaling, quantization, and transform. Such artifacts could otherwisecause inaccurate prediction (and create additional artifacts) whensubsequent blocks are predicted.

The filter control analysis component 227 and the in-loop filterscomponent 225 apply the filters to the residual blocks and/or toreconstructed image blocks. For example, the transformed residual blockfrom the scaling and inverse transform component 229 may be combinedwith a corresponding prediction block from intra-picture predictioncomponent 217 and/or motion compensation component 219 to reconstructthe original image block. The filters may then be applied to thereconstructed image block. In some examples, the filters may instead beapplied to the residual blocks. As with other components in FIG. 2, thefilter control analysis component 227 and the in-loop filters component225 are highly integrated and may be implemented together, but aredepicted separately for conceptual purposes. Filters applied to thereconstructed reference blocks are applied to particular spatial regionsand include multiple parameters to adjust how such filters are applied.The filter control analysis component 227 analyzes the reconstructedreference blocks to determine where such filters should be applied andsets corresponding parameters. Such data is forwarded to the headerformatting and CABAC component 231 as filter control data for encoding.The in-loop filters component 225 applies such filters based on thefilter control data. The filters may include a deblocking filter, anoise suppression filter, a SAO filter, and an adaptive loop filter.Such filters may be applied in the spatial/pixel domain (e.g., on areconstructed pixel block) or in the frequency domain, depending on theexample.

When operating as an encoder, the filtered reconstructed image block,residual block, and/or prediction block are stored in the decodedpicture buffer component 223 for later use in motion estimation asdiscussed above. When operating as a decoder, the decoded picture buffercomponent 223 stores and forwards the reconstructed and filtered blockstoward a display as part of an output video signal. The decoded picturebuffer component 223 may be any memory device capable of storingprediction blocks, residual blocks, and/or reconstructed image blocks.

The header formatting and CABAC component 231 receives the data from thevarious components of codec system 200 and encodes such data into acoded bitstream for transmission toward a decoder. Specifically, theheader formatting and CABAC component 231 generates various headers toencode control data, such as general control data and filter controldata. Further, prediction data, including intra-prediction and motiondata, as well as residual data in the form of quantized transformcoefficient data are all encoded in the bitstream. The final bitstreamincludes all information desired by the decoder to reconstruct theoriginal partitioned video signal 201. Such information may also includeintra-prediction mode index tables (also referred to as codeword mappingtables), definitions of encoding contexts for various blocks,indications of most probable intra-prediction modes, an indication ofpartition information, etc. Such data may be encoded by employingentropy coding. For example, the information may be encoded by employingcontext adaptive variable length coding (CAVLC), CABAC, syntax-basedcontext-adaptive binary arithmetic coding (SBAC), probability intervalpartitioning entropy (PIPE) coding, or another entropy coding technique.Following the entropy coding, the coded bitstream may be transmitted toanother device (e.g., a video decoder) or archived for latertransmission or retrieval.

FIG. 3 is a block diagram illustrating an example video encoder 300.Video encoder 300 may be employed to implement the encoding functions ofcodec system 200 and/or implement steps 101, 103, 105, 107, and/or 109of operating method 100. Encoder 300 partitions an input video signal,resulting in a partitioned video signal 301, which is substantiallysimilar to the partitioned video signal 201. The partitioned videosignal 301 is then compressed and encoded into a bitstream by componentsof encoder 300.

Specifically, the partitioned video signal 301 is forwarded to anintra-picture prediction component 317 for intra-prediction. Theintra-picture prediction component 317 may be substantially similar tointra-picture estimation component 215 and intra-picture predictioncomponent 217. The partitioned video signal 301 is also forwarded to amotion compensation component 321 for inter-prediction based onreference blocks in a decoded picture buffer component 323. The motioncompensation component 321 may be substantially similar to motionestimation component 221 and motion compensation component 219. Theprediction blocks and residual blocks from the intra-picture predictioncomponent 317 and the motion compensation component 321 are forwarded toa transform and quantization component 313 for transform andquantization of the residual blocks. The transform and quantizationcomponent 313 may be substantially similar to the transform scaling andquantization component 213. The transformed and quantized residualblocks and the corresponding prediction blocks (along with associatedcontrol data) are forwarded to an entropy coding component 331 forcoding into a bitstream. The entropy coding component 331 may besubstantially similar to the header formatting and CABAC component 231.

The transformed and quantized residual blocks and/or the correspondingprediction blocks are also forwarded from the transform and quantizationcomponent 313 to an inverse transform and quantization component 329 forreconstruction into reference blocks for use by the motion compensationcomponent 321. The inverse transform and quantization component 329 maybe substantially similar to the scaling and inverse transform component229. In-loop filters in an in-loop filters component 325 are alsoapplied to the residual blocks and/or reconstructed reference blocks,depending on the example. The in-loop filters component 325 may besubstantially similar to the filter control analysis component 227 andthe in-loop filters component 225. The in-loop filters component 325 mayinclude multiple filters as discussed with respect to in-loop filterscomponent 225. The filtered blocks are then stored in a decoded picturebuffer component 323 for use as reference blocks by the motioncompensation component 321. The decoded picture buffer component 323 maybe substantially similar to the decoded picture buffer component 223.

FIG. 4 is a block diagram illustrating an example video decoder 400.Video decoder 400 may be employed to implement the decoding functions ofcodec system 200 and/or implement steps 111, 113, 115, and/or 117 ofoperating method 100. Decoder 400 receives a bitstream, for example froman encoder 300, and generates a reconstructed output video signal basedon the bitstream for display to an end user.

The bitstream is received by an entropy decoding component 433. Theentropy decoding component 433 is configured to implement an entropydecoding scheme, such as CAVLC, CABAC, SBAC, PIPE coding, or otherentropy coding techniques. For example, the entropy decoding component433 may employ header information to provide a context to interpretadditional data encoded as codewords in the bitstream. The decodedinformation includes any desired information to decode the video signal,such as general control data, filter control data, partitioninformation, motion data, prediction data, and quantized transformcoefficients from residual blocks. The quantized transform coefficientsare forwarded to an inverse transform and quantization component 429 forreconstruction into residual blocks. The inverse transform andquantization component 429 may be similar to inverse transform andquantization component 329.

The reconstructed residual blocks and/or prediction blocks are forwardedto intra-picture prediction component 417 for reconstruction into imageblocks based on intra-prediction operations. The intra-pictureprediction component 417 may be similar to intra-picture estimationcomponent 215 and an intra-picture prediction component 217.Specifically, the intra-picture prediction component 417 employsprediction modes to locate a reference block in the frame and applies aresidual block to the result to reconstruct intra-predicted imageblocks. The reconstructed intra-predicted image blocks and/or theresidual blocks and corresponding inter-prediction data are forwarded toa decoded picture buffer component 423 via an in-loop filters component425, which may be substantially similar to decoded picture buffercomponent 223 and in-loop filters component 225, respectively. Thein-loop filters component 425 filters the reconstructed image blocks,residual blocks and/or prediction blocks, and such information is storedin the decoded picture buffer component 423. Reconstructed image blocksfrom decoded picture buffer component 423 are forwarded to a motioncompensation component 421 for inter-prediction. The motion compensationcomponent 421 may be substantially similar to motion estimationcomponent 221 and/or motion compensation component 219. Specifically,the motion compensation component 421 employs motion vectors from areference block to generate a prediction block and applies a residualblock to the result to reconstruct an image block. The resultingreconstructed blocks may also be forwarded via the in-loop filterscomponent 425 to the decoded picture buffer component 423. The decodedpicture buffer component 423 continues to store additional reconstructedimage blocks, which can be reconstructed into frames via the partitioninformation. Such frames may also be placed in a sequence. The sequenceis output toward a display as a reconstructed output video signal.

FIG. 5 is a schematic diagram illustrating an example bitstream 500containing an encoded video sequence. For example, the bitstream 500 canbe generated by a codec system 200 and/or an encoder 300 for decoding bya codec system 200 and/or a decoder 400. As another example, thebitstream 500 may be generated by an encoder at step 109 of method 100for use by a decoder at step 111.

The bitstream 500 includes a sequence parameter set (SPS) 510, aplurality of picture parameter sets (PPSs) 512, a plurality of sliceheaders 514, and image data 520. An SPS 510 contains sequence datacommon to all the pictures in the video sequence contained in thebitstream 500. Such data can include picture sizing, bit depth, codingtool parameters, bit rate restrictions, etc. The PPS 512 containsparameters that are specific to each picture. Hence, there may be onePPS 512 per picture in the video sequence. The PPS 512 can indicatecoding tools available for slices in corresponding pictures,quantization parameters, offsets, picture specific coding toolparameters (e.g., filter controls), etc. The slice header 514 containsparameters that are specific to each slice in a picture. Hence, theremay be one slice header 514 per slice in the video sequence. The sliceheader 514 may contain slice type information, picture order counts(POCs), reference picture lists, prediction weights, tile entry points,deblocking parameters, etc.

The image data 520 contains video data encoded according tointer-prediction and/or intra-prediction as well as correspondingtransformed and quantized residual data. Such image data 520 is sortedaccording to the partitioning used to partition the image prior toencoding. For example, the image in the image data 520 is divided intoslices 521. Each slice 521 is further divided into tiles 523. The tiles523 are further divided into CTUs 527. The CTUs 527 are further dividedinto coding blocks based on coding trees. The coding blocks can then beencoded/decoded according to prediction mechanisms. An image/picture cancontain one or more slices 521. One slice header 514 is employed perslice 521. Each slice 521 can contain one or more tiles 523, which canthen contain a plurality of CTUs 527.

Each slice 521 may be a rectangle defined by a tile 523 at an upper leftcorner and a tile 523 at a bottom right corner. Unlike in other codingsystems, a slice 521 may not traverse the entire width of a picture. Aslice 521 is the smallest unit that can be separately displayed by adecoder. Hence, splitting slices 521 into smaller units allows forsub-pictures to be generated in a manner that is granular enough todisplay desired areas of a picture. For example, in a virtual reality(VR) context, a picture may contain an entire viewable sphere of data,but a user may only view a sub-picture on a head mounted display.Smaller slices 521 allows for such sub-pictures to be separatelysignaled. A slice 521 is also generally signaled in a separate VCL NALunit 533. Also, a slice 521 may not allow prediction based on otherslices 521, which allows each slice 521 to be coded independently ofother slices 521.

The slices 521 are partitioned into an integer number of tiles 523. Atile 523 is a partitioned portion of a slice 521 created by horizontaland vertical boundaries. Tiles 523 may be coded in raster scan order,and may or may not allow prediction based on other tiles 523, dependingon the example. Each tile 523 may have a unique tile ID 524 in thepicture. A tile ID 524 is a numerical identifier that can be used todistinguish one tile 523 from another. A tile ID 524 may take the valueof a tile index that increases numerically in raster scan order. Rasterscan order is left to right and top to bottom. The tile IDs 524 may alsoemploy other numerical values. However, the tile ID 524 should alwaysincrease in raster scan order to support the computations discussedherein. For example, the boundaries of the slice 521 can be determinedaccording to the tile ID 524 of the tile 523 at the upper left corner ofthe slice 521 and the tile ID 524 of the tile 523 at the bottom rightcorner of the slice 521. When the tile ID 524 is a different value froma tile index, a conversion mechanism can be signaled in the bitstream500, for example in the PPS 512. Further, each tile 523 may beassociated with an entry point offset 525. The entry point offset 525indicates the location of the first bit of coded data associated withthe tile 523. The first tile 523 may have an entry point offset 525 ofzero and further tiles 523 may each have an entry point offset 525 equalto the number of bits of coded data in preceding tiles 523. As such, thenumber of the entry point offset 525 can be inferred to be one less thanthe number of tiles 523.

Tiles 523 are further divided into CTUs 527. A CTU 527 is a sub-portionof a tile 523 that can be further subdivided by a coding tree structureinto coding blocks that can be encoded by an encoder and decoded by adecoder. The CTUs 527 are each associated with a CTU address 529. A CTUaddress 529 denotes the location of a corresponding CTU 527 in thebitstream 500. Specifically, a CTU address 529 may denote the locationof a corresponding CTU 527 in a VCL NAL unit 533. In some examples, theCTU addresses 529 for the CTUs 527 may be explicitly signaled, forexample in the PPS 512. In other examples, CTU addresses 529 can bederived by the decoder. For example, the CTU addresses 529 can beassigned based on the tile ID 524 of the tile 523 that contains thecorresponding CTUs 527. In such a case, the decoder can determine thetiles 523 in a slice 521 based on the tile IDs 524 of the upper left andbottom right tiles 523. The decoder can then use the determined tiles523 in the slice 521 to determine the number of CTUs 527 in the slice521. Further, the decoder can use the known tile IDs 524 and the numberof CTUs 527 to determine the CTU addresses 529. In addition, as thedecoder is aware of the number of CTUs 527, a flag that indicateswhether each CTU 527 is the last CTU 527 in a VCL NAL unit 533 can beomitted. This is because the decoder can determine which CTU 527 is thelast CTU 527 in a VCL NAL unit 533 by being aware of the number of CTUs527 in the slice 521, which is contained in the VCL NAL unit 533.However, a padding bit may be placed after the last CTU 527 in a tile523 in order to assist in distinguishing between tiles 523 in someexamples. As can be seen, signaling slice 521 boundaries based on tileIDs 524 can allow the decoder to infer a significant amount of data,which can then be omitted from the bitstream 500 in order to increasecoding efficiency.

The bitstream 500 is positioned into VCL NAL units 533 and Non-VCL NALunits 531. A NAL unit is a coded data unit sized to be placed as apayload for a single packet for transmission over a network. A VCL NALunit 533 is a NAL unit that contains coded video data. For example, eachVCL NAL unit 533 may contain one slice 521 of data includingcorresponding tiles 523, CTUs 527 and coding blocks. A Non-VCL NAL unit531 is a NAL unit that contains supporting syntax, but does not containcoded video data. For example, a Non-VCL NAL unit 531 may contain theSPS 510, a PPS 512, a slice header 514, etc. As such, the decoderreceives the bitstream 500 in discrete VCL NAL unit 533 and Non-VCL NALunits 531. In streaming applications, the decoder may decode a presentvideo data without waiting for the entire bitstream 500 to be received.As such, tile IDs 524, entry point offsets 525, and CTU addresses 529allow the decoder to correctly locate the video data in the VCL NAL unit533 for fast decoding, parallel processing, and other video displaymechanisms. Accordingly, computing tile IDs 524, entry point offsets525, and/or CTU addresses 529 allows for the implementation of efficientdecoding and display mechanisms while reducing the size of the bitstream500 and hence increasing coding efficiency.

FIG. 6 is a schematic diagram illustrating an example image 600partitioned for coding. For example, an image 600 can be encoded in anddecoded from a bitstream 500, for example by a codec system 200, anencoder 300, and/or a decoder 400. Further, the image 600 can bepartitioned to support encoding and decoding according to method 100.

The image 600 can be partitioned into slices 621, tiles 623, and CTUs627, which may be substantially similar to slices 521, tiles 523, andCTUs 527, respectively. In FIG. 6, the slices 621 are depicted by boldlines with alternative white backgrounds and hashing to graphicallydifferentiate between slices 621. The tiles 623 are shown by dashedlines. Tile 623 boundaries positioned on slice 621 boundaries aredepicted as dashed bold lines and tile 623 boundaries that are notpositioned on slice 621 boundaries are depicted as non-bold dashedlines. The CTU 627 boundaries are depicted as solid non-bold linesexcept for locations where the CTU 627 boundaries are covered by tile623 or slice 621 boundaries. In this example, image 600 includes nineslices 621, twenty four tiles 623, and two hundred sixteen CTUs 627.

As shown, a slice 621 is a rectangle with boundaries that may be definedby the included tiles 623. The slice 621 may not extend across theentire width of the image 600. Tiles 623 can be generated in the slices621 according to rows and columns. CTUs 627 can then be partitioned fromthe tiles 623 to create image 600 partitions suitable to be subdividedinto coding blocks for coding according to inter-prediction and/orintra-prediction.

By employing the forgoing, video coding systems can be improved. Forexample, slices are designed such that CTUs contained in a slice may notbe simply a set of CTUs of a picture following a CTU raster scan orderof the picture. But rather a slice is defined as a set of CTUs thatcover a rectangular region of a picture. Further, each slice is in itsown NAL unit. Also, the addresses of the CTUs contained in a slice canbe signaled by signaling, in the slice header, the CTU addresses inraster scan order of the top-left and bottom-right CTUs in the slice.Further, slices are designed to contain and only contain a set ofcomplete tiles covering a rectangular region of a picture. Each slice isin its own NAL unit. This way, the purpose of having more than one slicemay be to put a set of tiles covering a rectangular region of a pictureinto a NAL unit. In some cases, there are one or more slices in apicture, and each of these slices can contain a set of complete tilescovering a rectangular region. There may also be one other slice in thepicture covering the rest of the tiles of the picture. The regioncovered by this slice may be a rectangular region with a hole that iscovered by other slices. For example, for region of interest purposes, apicture may contain two slices in which one slice contains a set ofcomplete tiles covering the region of interest and the other slicecontains the remaining tiles of the picture.

The addresses of the CTUs contained in a slice may be explicitly orimplicitly signaled by the tile IDs of the tiles contained in the slice.For efficient signaling, only the tile IDs of the top-left and thebottom-right tiles may be signaled in some examples. For furtherimproved signaling efficiency, a flag indicating whether the slicecontains a single tile can signaled, and if yes, only one tile ID may besignaled. In other cases, all tile IDs contained in a slice aresignaled. In some examples, tile ID values are assigned to be the sameas the tile index within the picture. The length, in bits, forexplicitly signaling tile IDs in a slice header for derivation of theaddresses of the CTUs contained in a slice, can be derived according tothe number of tiles in the picture (e.g., cell of log two of number oftiles in a picture). The number of tiles in the picture can be eitherexplicitly signaled in a parameter set or derived per the tileconfiguration signaled in a parameter set. In some examples, the length,in bits, for explicitly signaling tile IDs in a slice header forderivation of the addresses of the CTUs contained in a slice can besignaled in a parameter set. In some examples, the number of entrypoints, which is equal to the number of tiles in the slice minus 1, isderived and is not signaled in the slice header. In another example,signaling of a flag for each CTU indicating whether the CTU is the endof a slice is avoided.

In some examples, slices and tiles are designed such that rewriting ofthe slice headers is not needed when extracting a set of tiles, such asmotion constrained tile sets (MCTSs), from a bitstream to create aconforming sub-bitstream. For example, the tile ID may be explicitlysignaled for each tile in the parameter set in which the tileconfiguration is signaled. The tile IDs are each unique within apicture. Tile IDs may not be continuous within a picture. However, tileIDs should be organized in increasing order (e.g., monotonouslyincreasing) in the direction of the tile raster scan of a picture. Withthis, the decoding order of slices in a picture can be restricted to bein increasing value of the tile ID of the top-left tile. When the tileID is not explicitly signaled and inferred to be the same as tile index,the following can be used for signaling tile ID values in slice headers.A flag indicating whether the slice is the first slice of the picturecan be signaled. When the flag indicating that the slice is the firstslice of the picture, the signaling of the tile ID of the top left tileof the slice can be omitted as it can be inferred to be the tile withlowest tile index (e.g., tile index zero—assuming tile index starts fromzero).

In another example, a picture may contain zero, one, or more MCTSs. AnMCTS may contain one or more tiles. When a tile in a slice is part of anMCTS, the MCTS is constrained so that all tiles in the slice are part ofthe same MCTS. The slice may be further constrained so that the tileconfiguration for all pictures containing tiles of an MCTS is the sameregarding the positions and sizes of the tiles within the MCTS. In someexamples, the slice is constrained such that an MCTS is exclusivelycontained in a slice. This has two consequences. In this case, each MCTSis in a separate NAL unit. Further, each MCTS is in rectangular shape.

The signaling of MCTSs may be as follows. A flag can be signaled in aslice header to indicate whether the slice contains NAL units with anMCTS in the access unit containing the corresponding slice. Othersupporting information for MCTS (e.g., profile, tier and levelinformation of sub-bitstream resulting from extracting the MCTS) issignaled in an SEI message. Alternatively, both the flag indication andsupporting information of MCTS can be signaled in an SEI message. Toenable signaling of treatment of MCTS boundaries as picture boundaries asyntax element indicating whether all tile boundaries are treated thesame as picture boundaries is signaled, for example in the parameter setwherein tile configuration is signaled. In addition, a syntax elementindicating whether all slice boundaries of a slice are treated the sameas picture boundaries may be signaled in the slice header, for examplewhen other syntax elements do not indicate that all tile boundaries aretreated the same as picture boundaries.

A syntax element indicating whether the in-loop filtering operations maybe applied across each tile boundary may be signaled only when syntaxdoes not otherwise indicate that all tile boundaries are treated thesame as picture boundaries. In this case, treating a tile boundary aspicture boundary indicates that, among other aspects, no in-loopfiltering operations may be applied across each tile boundary. In otherexamples, a syntax element indicating whether the in-loop filteringoperations may be applied across each tile boundary is signaledindependently of indications of whether all tile boundaries are treatedthe same as picture boundaries. In this case, treating a tile boundaryas picture boundary indicates that in-loop filtering operations maystill be applied across each tile boundary.

In some examples, an MCTS boundary is treated as a picture boundary.Further, the syntax element in the slice header that indicates whetherthe slice boundary is treated the same as the picture boundary can alsobe made conditional to the flag that indicates whether the slicecontains MCTS. In some cases, the value of a flag indicating that theMCTS boundary is to be treated as a picture boundary can be inferredwhen the flag in the slice header indicates the slice contains MCTS.

When the boundaries of a tile or slice are indicated to be treated aspicture boundaries, the following applies. In the derivation process fortemporal luma motion vector prediction, the right and bottom pictureboundary positions used in the process, indicated bypic_height_in_luma_samples−1 and pic_width_in_luma_samples−1,respectively, are replaced with the right and the bottom boundarypositions, respectively, of the tile or slice, in units of luma samples.In the luma sample interpolation process, the left, right, top, andbottom picture boundary positions used in the process, indicated by 0,pic_height_in_luma_samples−1, 0, pic_width_in_luma_samples−1,respectively, are replaced with the left, right, top, and bottomboundary positions, respectively, of the tile or slice, in units of lumasamples, respectively. In the chroma sample interpolation process, theleft, right, top, and bottom picture boundary positions used in theprocess, indicated by 0, pic_height_in_luma_samples/SubWidthC−1, 0,pic_width_in_luma_samples/SubWidthC−1, respectively, are replaced withthe left, right, top, and bottom boundary positions, respectively, ofthe tile or slice, in units of chroma samples, respectively.

The preceding mechanisms can be implemented as follows. A slice isdefined as an integer number of tiles that cover a rectangular region ofa picture and that are exclusively contained in a single NAL unit. Aslice header is defined as a part of a coded slice containing the dataelements pertaining to all tiles represented in the slice. A tile isdefined as a rectangular region of CTUs within a particular tile columnand a particular tile row in a picture. A tile column is defined as arectangular region of CTUs having a height equal to the height of thepicture and a width specified by syntax elements in the pictureparameter set. A tile row is defined as a rectangular region of CTUshaving a height specified by syntax elements in the picture parameterset and a width equal to the width of the picture. A tile scan isdefined as a specific sequential ordering of CTUs partitioning a picturein which the CTUs are ordered consecutively in CTU raster scan in a tilewhereas tiles in a picture are ordered consecutively in a raster scan ofthe tiles of the picture.

This section specifies how a picture is partitioned into slices andtiles. Pictures are divided into slices and tiles. A slice is a sequenceof tiles that cover a rectangular region of a picture. A tile is asequence of CTUs that cover a rectangular region of a picture.

When a picture is coded using three separate color planes(separate_colour_plane_flag is equal to 1), a slice contains only CTUsof one color component being identified by the corresponding value ofcolour_plane_id, and each color component array of a picture includesslices having the same colour_plane_id value. Coded slices withdifferent values of colour_plane_id within a picture may be interleavedwith each other under the constraint that for each value ofcolour_plane_id, the coded slice NAL units with that value ofcolour_plane_id shall be in the order of increasing CTU address in tilescan order for the first CTU of each coded slice NAL unit. It should benoted that when separate_colour_plane_flag is equal to 0, each CTU of apicture is contained in exactly one slice. Whenseparate_colour_plane_flag is equal to 1, each CTU of a color componentis contained in exactly one slice (e.g., information for each CTU of apicture is present in exactly three slices and these three slices havedifferent values of colour_plane_id).

The following divisions of processing elements of this specificationform spatial or component-wise partitioning: the division of eachpicture into components; the division of each component into CTBs; thedivision of each picture into tile columns; the division of each pictureinto tile rows; the division of each tile column into tiles; thedivision of each tile row into tiles; the division of each tile intoCTUs; the division of each picture into slices; the division of eachslice into tiles; the division of each slice into CTUs; the division ofeach CTU into CTBs; the division of each CTB into coding blocks, exceptthat the CTBs are incomplete at the right component boundary when thecomponent width is not an integer multiple of the CTB size and the CTBsare incomplete at the bottom component boundary when the componentheight is not an integer multiple of the CTB size; the division of eachCTU into coding units, except that the CTUs are incomplete at the rightpicture boundary when the picture width in luma samples is not aninteger multiple of the luma CTB size and the CTUs are incomplete at thebottom picture boundary when the picture height in luma samples is notan integer multiple of the luma CTB size; the division of each codingunit into transform units; the division of each coding unit into codingblocks; the division of each coding block into transform blocks; and thedivision of each transform unit into transform blocks.

Inputs into the derivation process for neighboring block availabilityare the luma location (xCurr, yCurr) of the top-left sample of thecurrent block relative to the top-left luma sample of the currentpicture, and the luma location (xNbY, yNbY) covered by a neighboringblock relative to the top-left luma sample of the current picture. Theoutputs of this process are the availability of the neighboring blockcovering the location (xNbY, yNbY), denoted as availableN. Theneighboring block availability availableN is derived as follows. If oneor more of the following conditions are true, availableN is set equal tofalse. The top_left_tile_id of the slice containing the neighboringblock differs in value from the top_left_tile_id of the slice containingthe current block or the neighboring block is contained in a differenttile than the current block.

The CTB raster and tile scanning process is as follows. The listColWidth[i] for i ranging from 0 to num_tile_columns_minus1, inclusive,specifying the width of the i-th tile column in units of CTBs, isderived as follows.

if( uniform_tile_spacing_flag )  for( i = 0; i <=num_tile_columns_minus1; i++ )   ColWidth[ i ] = ( ( i + 1 ) *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) − ( i *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) else {  ColWidth[num_tile_columns_minus1 ] = PicWidthInCtbsY (6-1)  for( i = 0; i <num_tile_columns_minus1; i++ ) {   ColWidth[ i ] =title_column_width_minus1[ i ] + 1   ColWidth[ num_tile_columns_minus1 ]−= ColWidth[ i ]  } } The list RowHeight[ j ] for j ranging from 0 tonum_tile_rows_minus1, inclusive, specifying the height of the j-th tilerow in units of CTBs, is derived as follows. if(uniform_tile_spacing_flag )  for( j = 0; j <= num_tile_rows_minus1; j++)   RowHeight[ j ] = ( ( j + 1) * PicHeightInCtbsY ) / (num_tile_rows_minus1 +1) − ( j * PicHeightInCtbsY ) /(num_tile_rows_minus1 + 1 ) else {  RowHeight[ num_tile_rows_minus1 ] =PicHeightInCtbsY (6-2)  for( j = 0; j < num_tile_rows_minus1; j++ ) {  RowHeight[ j ] = tile_row_height_minus1[ j ] + 1   RowHeight[num_tile_rows_minus1 ] −= RowHeight[ j ]  } }

The list ColBd[i] for i ranging from 0 to num_tile_columns_minus1+1,inclusive, specifying the location of the i-th tile column boundary inunits of CTBs, is derived as follows:

for(ColBd[0]=0,i=0;i<=num_tile_columns_minus;i++)ColBd[i+1]=ColBd[i]+ColWidth[i]  (6-3)

The list RowBd[j] for j ranging from 0 to num_tile_rows_minus1+1,inclusive, specifying the location of the j-th tile row boundary inunits of CTBs, is derived as follows:

for(RowBd[0]=0,j=0;j<=num_tile_rows_minus1;j++)RowBd[j+1]=RowBd[j]+RowHeight[j]  (6-4)

The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in CTB raster scan of a picture to a CTB address in tile scan,is derived as follows:

for( ctbAddrRs = 0; ctbAddrRs < PicSizeInCtbsY; ctbAddrRs++ ) {  tbX =ctbAddrRs % PicWidthInCtbsY  tbY = ctbAddrRs / PicWidthInCtbsY  for( i =0; i <= num_tile_columns_minus1; i++ )   if( tbX >= ColBd[ i ] )   tileX = i  for( j = 0; j <= num_tile_rows_minus1; j++ ) (6-5)   if(tbY >= RowBd[ j ] )    tileY = j  CtbAddrRsToTs[ ctbAddrRs ] = 0  for( i= 0; i < tileX; i++ )   CtbAddrRsToTs[ ctbAddrRs ] += RowHeight[ tileY] * ColWidth[ i ]  for( j = 0; j < tileY; j++ )   CtbAddrRsToTs[ctbAddrRs ] += PicWidthInCtbsY * RowHeight[ j ]  CtbAddrRsToTs[ctbAddrRs ] += ( tbY − RowBd[ tileY ] ) * ColWidth[ tileX ] + tbX −ColBd[ tileX ] }

The list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a CTB address in CTB raster scan of a picture,is derived as follows:

for(ctbAddrRs=0;ctbAddrRs<PicSizeInCtbsY;ctbAddrRs++)CtbAddrTsToRs[CtbAddrRsToTs[ctbAddrRs]]=ctbAddrRs  (6-6)

The list TileId[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a tile ID, is derived as follows:

for( j = 0, tileIdx = 0; j <= num_tile_rows_minus1; j++ )  for( i = 0; i<= num_tile_columns_minus1; i++, tileIdx++ )   for( y = RowBd[ j ]; y<RowBd[ j + 1 ]; y++ )      (6-7)    for( x = ColBd[ i ]; x < ColBd[ i +1 ]; x++ )     TileId[ CtbAddrRsToTs[ y * PicWidthInCtbsY+ x ] ] =     explicit_tile_id_flag ? tile_id_val[ i ][ j ] : tileIdxThe list NumCtusInTile[tileIdx] for tileIdx ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a tile indexto the number of CTUs in the tile, is derived as follows:

for(j=0,tileIdx=0;j<=num_tile_rows_minus1;j++)for(i=0;i<=num_tile_columns_minus1;i++,tileIdx++)NumCtusInTile[tileIdx]=ColWidth[i]*RowHeight[j]  (6-8)

The set TileIdToIdx[tileId] for a set of NumTilesInPic tileId valuesspecifying the conversion from a tile ID to a tile index and the listFirstCtbAddrTs[tileIdx] for tileIdx ranging from 0 to NumTilesInPic−1,inclusive, specifying the conversion from a tile ID to the CTB addressin tile scan of the first CTB in the tile are derived as follows:

for( ctbAddrTs = 0, tileIdx = 0, tileStartFlag = 1; ctbAddrTs <PicSizeInCtbsY; ctbAddrTs++ ) {  if( tileStartFlag) {   TileIdToIdx[TileId[ ctbAddrTs ] ] = tileIdx   FirstCtbAddrTs[ tileIdx ] = ctbAddrTs(6-9)   tileStartFlag = 0  }  tileEndFlag = ctbAddrTs = = PicSizeInCtbsY− 1 | | TileId [ ctbAddrTs + 1 ] != TileId[ ctbAddrTs ]  if( tileEndFlag) {   tileIdx++   tileStartFlag = 1  } }The values of ColumnWidthInLumaSamples[i], specifying the width of thei-th tile column in units of luma samples, are set equal toColWidth[i]<<Ctb Log 2SizeY for i ranging from 0 tonum_tile_columns_minus1, inclusive. The values ofRowHeightInLumaSamples[j], specifying the height of the j-th tile row inunits of luma samples, are set equal to RowHeight[j]<<Ctb Log 2SizeY forj ranging from 0 to num_tile_rows_minus1, inclusive.

The picture parameter set RBSP syntax is as follows:

Descriptor pic_parameter_set_rbsp( ) {  pps_pic_parameter_set_id ue(v) pps_seq_parameter_set_id ue(v)  transform_skip_enabled_flag u(1) single_tile_in_pic_flag u(1)  if( !single_tile_in_pic_flag ) {  num_tile_columns_minus1 ue(v)   num_tile_rows_minus1 ue(v)  } tile_id_len_minus1 ue(v)  explicit_tile_id_flag u(1)  if(explicit_tile_id_flag)   for( i = 0; i <= num_tile_columns_minus1; i++)   for(j = 0; j <= num_tile_columns_minus1; j++)     tile_id_val[ i ][ j] u(v)  if( !single_tile_in_pic_flag) {   uniform_tile_spacing_flag u(1)  if( !uniform_tile_spacing_flag) {    for( i = 0; i <num_tile_columns_minus1; i++)     tile_column_width_minus1[ i ] ue(v)   for( i = 0; i < num_tile_rows_minus1; i++)    tile_row_height_minus1[ i ] ue(v)   }  tile_boundary_treated_as_pic_boundary_flag u(1)   if(!tile_boundary_treated_as_pic_boundary_flag)   loop_filter_across_tiles_enabled_flag u(1)  }  rbsp_trailing_bits( )}

The slice header syntax is changed as follows.

TABLE 2 Descriptor slice_healer( ) {  slice_pic_parameter_set_id ue(v) single_tile_in_slice_flag // Same note as below u(1)  top_left_tile_id// Note that this is needed even u(v) when there is only one tile in thepicture to enable extraction of a single motion-constrained tile to be aconforming bitstream without the need of changing the slice header.  if(!single_tile_in_slice_flag )   bottom_right_tile_id u(v)  slice_typeue(v)  if ( slice_type != I)   log2_diff_ctu_max_bt_size ue(v) dep_quant_enabled_flag u(1)  if( !dep_quant_enabled_flag )  sign_data_hiding_enabled_flag u(1)  if(!tile_boundary_treated_as_pic_boundary_flag )  slice_boundary_treated_as_pic_boundary_flag  if(!single_tile_in_slice_flag ) {   offset_len_minus1 ue(v)   for( i = 0; i< NumTilesInSlice −; i++)    entry_point_offset_minus1 u(v)  } byte_alignment( ) }

The slice_data( ) syntax is as follows:

TABLE 3 Descrip- tor slice_data( ) {  tileIdx =TileIdToIdx[top_left_tile_id ]  for( j = 0; j < NumTileRowsInSlice; j++,tileIdx+= num_tile_columns_minus1 +1) {   for( i = 0, CurrTileIdx=tileIdx; i <NumTileColumnsInSlice; i++, CurrTileIdx++) {    ctbAddrInTs=FirstCtbAddrTs[ CurrTileIdx ]    for( k = 0; k < NumCtusInTile[CurrTileIdx ]; k++, ctbAddrInTs++) {     CtbAddrInRs =CtbAddrTsToRs[ctbAddrInTs ]     coding_tree_unit( )    }   end_of_tile_one_bit /* equal to 1 */ ae(v)    if( i <NumTileRowsInSlice − || j < NumTileColumnsInSlice − 1)    byte_alignment( )   }  } }

The Picture parameter set RBSP semantics are as follows. Thesingle_tile_in_pic_flag is set equal to one to specify that there isonly one tile in each picture referring to the PPS. Thesingle_tile_in_pic_flag is set equal to zero to specify that there ismore than one tile in each picture referring to the PPS. Bitstreamconformance may require that the value of single_tile_in_pic_flag shallbe the same for all PPSs that are activated within a coded videosequence (CVS). The num_tile_columns_minus1 plus 1 specifies the numberof tile columns partitioning the picture. The num_tile_columns_minus1shall be in the range of zero to PicWidthInCtbsY−1, inclusive. When notpresent, the value of num_tile_columns_minus1 is inferred to be equal tozero. The num_tile_rows_minus1 plus 1 specifies the number of tile rowspartitioning the picture. The num_tile_rows_minus1 shall be in the rangeof zero to PicHeightInCtbsY−1, inclusive. When not present, the value ofnum_tile_rows_minus1 is inferred to be equal to zero. The variableNumTilesInPic is set equal to(num_tile_columns_minus1+1)*(num_tile_rows_minus1+1).

When single_tile_in_pic_flag is equal to zero, NumTilesInPic shall begreater than zero. The tile_id_len_minus1 plus 1 specifies the number ofbits used to represent the syntax element tile_id_val[i][j], whenpresent, in the PPS and the syntax elements top_left_tile_id andbottom_right_tile_id, when present, in slice headers referring to thePPS. The value of tile_id_len_minus shall be in the range of Ceil(Log2(NumTilesInPic) to 15, inclusive. The explicit_tile_id_flag is setequal to one to specify that tile ID for each tile is explicitlysignaled. The explicit_tile_id_flag is set equal to zero to specify thatthe tile IDs are not explicitly signaled. The tile_id_val[i][j]specifies the tile ID of the tile of the i-th tile column and the j-thtile row. The length of tile_id_val[i][j] is tile_id_len_minus1+1 bits.

For any integer min the range of zero to num_tile_columns_minus1,inclusive, and any integer n in the range of zero tonum_tile_rows_minus1, inclusive, tile_id_val[i][j] shall not be equal totile_id_val[m][n] when i is not equal to m or j is not equal to n, andtile_id_val[i][j] shall be less than tile_id_val[m][n] whenj*(num_tile_columns_minus1+1)+i is less thann*(num_tile_columns_minus1+1)+m. The uniform_tile_spacing_flag is setequal to one to specify that tile column boundaries and likewise tilerow boundaries are distributed uniformly across the picture. Theuniform_tile_spacing_flag is set equal to zero to specify that tilecolumn boundaries and likewise tile row boundaries are not distributeduniformly across the picture but signaled explicitly using the syntaxelements tile_column_width_minus1[i] and tile_row_height_minus1[i]. Whennot present, the value of uniform_tile_spacing_flag is inferred to beequal to 1. The tile_column_width_minus[i] plus 1 specifies the width ofthe i-th tile column in units of CTBs. The tile_row_height_minus1[i]plus 1 specifies the height of the i-th tile row in units of CTBs.

The following variables are derived by invoking the CTB raster and tilescanning conversion process: the list ColWidth[i] for i ranging from 0to num_tile_columns_minus, inclusive, specifying the width of the i-thtile column in units of CTBs; the list RowHeight[j] for j ranging from 0to num_tile_rows_minus1, inclusive, specifying the height of the j-thtile row in units of CTBs; the list ColBd[i] for i ranging from 0 tonum_tile_columns_minus1+1, inclusive, specifying the location of thei-th tile column boundary in units of CTBs; the list RowBd[j] for jranging from 0 to num_tile_rows_minus1+1, inclusive, specifying thelocation of the j-th tile row boundary in units of CTBs; the listCtbAddrRsToTs[ctbAddrRs] for ctbAddrRs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in the CTB raster scan of a picture to a CTB address in the tilescan; the list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in the tile scan to a CTB address in the CTB raster scan of apicture; the list TileId[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a tile ID; the list NumCtusInTile[tileIdx] fortileIdx ranging from 0 to PicSizeInCtbsY−1, inclusive, specifying theconversion from a tile index to the number of CTUs in the tile; the setTileIdToIdx[tileId] for a set of NumTilesInPic tileId values specifyingthe conversion from a tile ID to a tile index and the listFirstCtbAddrTs[tileIdx] for tileIdx ranging from 0 to NumTilesInPic−1,inclusive, specifying the conversion from a tile ID to the CTB addressin tile scan of the first CTB in the tile; the listsColumnWidthInLumaSamples[i] for i ranging from 0 tonum_tile_columns_minus1, inclusive, specifying the width of the i-thtile column in units of luma samples; and the listRowHeightInLumaSamples[j] for j ranging from 0 to num_tile_rows_minus1,inclusive, specifying the height of the j-th tile row in units of lumasamples.

The values of ColumnWidthInLumaSamples[i] for i ranging from 0 tonum_tile_columns_minus1, inclusive, and RowHeightInLumaSamples[j] for jranging from 0 to num_tile_rows_minus1, inclusive, shall all be greaterthan 0. The tile_boundary_treated_as_picture_boundary_flag is set equalto one to specify that each tile boundary is treated the same as thepicture boundary in the decoding process for pictures referring to thePPS. The tile_boundary_treated_as_picture_boundary_flag is set equal tozero to specify that each tile boundary may or may not be treated thesame as the picture boundary in the decoding process for picturesreferring to the PPS. When not present, the value oftile_boundary_treated_as_picture_boundary_flag is inferred to be equalto one. The loop_filter_across_tiles_enabled_flag is set equal to one tospecify that in-loop filtering operations may be performed across tileboundaries in pictures referring to the PPS. Theloop_filter_across_tiles_enabled_flag is set equal to zero to specifythat in-loop filtering operations are not performed across tileboundaries in pictures referring to the PPS. The in-loop filteringoperations include the deblocking filter, sample adaptive offset filter,and adaptive loop filter operations. When not present, the value ofloop_filter_across_tiles_enabled_flag is inferred to be equal to zero.

The slice header semantics are as follows. When present, the value ofthe slice header syntax element slice_pic_parameter_set_id shall be thesame in all slice headers of a coded picture. Theslice_pic_parameter_set_id specifies the value ofpps_pic_parameter_set_id for the PPS in use. The value ofslice_pic_parameter_set_id shall be in the range of 0 to 63, inclusive.The single_tile_in_slice_flag is set equal to one to specify that thereis only one tile in the slice. The singlepicture_in_pic_flag is setequal to zero to specify that there is more than one tile in the slice.The top_left_tile_id specifies the tile ID of the tile located at thetop-left corner of the slice. The length of top_left_tile_id istile_id_len_minus1+1 bits. The value of top_left_tile_id shall not beequal to the value of top_left_tile_id of any other coded slice NAL unitof the same coded picture. When there is more than one slice in apicture, the decoding order of the slices in the picture shall be inincreasing value of top_left_tile_id. The bottom_right_tile_id specifiesthe tile ID of the tile located at the bottom-right corner of the slice.The length of bottom_right_tile_id is tile_id_len_minus1+1 bits. Whennot present, the value of bottom_right_tile_id is inferred to be equalto top_left_tile_id.

The variables NumTileRowsInSlice, NumTileColumnsInSlice, andNumTilesInSlice are derived as follows:

deltaTileIdx=TileIdToIdx[bottom_right_tile_id]−TileIdToIdx[top_left_tile_id]NumTileRowsInSlice=(deltaTileIdx/(num_tile_columns_minus1+1))+1NumTileColumnsInSlice=(deltaTileIdx%(num_tile_columns_minus1+1))+1NumTilesInSlice=NumTileRowsInSlice*NumTileColumnsInSlice  (7-25)

The slice_type specifies the coding type of the slice according to table4.

TABLE 4 slice_type Name of slice_type 0 B (B slice) 1 P (P slice) 2 I (Islice)

When nal_unit_type has a value in the range of TBD, inclusive, e.g., thepicture is an Intra Random Access Picture (IRAP) picture, slice_typeshall be equal to two. The log 2_diff_ctu_max_bt_size specifies thedifference between the luma CTB size and the maximum luma size (width orheight) of a coding block that can be split using a binary split. Thevalue of log 2_diff_ctu_max_bt_size shall be in the range of zero to CtbLog 2SizeY−MinCb Log 2SizeY, inclusive. When log 2_diff_ctu_max_bt_sizeis not present, the value of log 2_diff_ctu_max_bt_size is inferred tobe equal to two.

The variables MinQt Log 2SizeY, MaxBt Log 2SizeY, MinBt Log 2SizeY,MaxTt Log 2SizeY, MinTt Log 2SizeY, MaxBtSizeY, MinBtSizeY, MaxTtSizeY,MinTtSizeY and MaxMttDepth are derived as follows:

MinQt Log 2SizeY=(slice_type==I)?MinQt Log 2SizeIntraY:MinQt Log2SizeInterY   (7-26)

MaxBt Log 2SizeY=Ctb Log 2SizeY−log 2_diff_ctu_max_bt_size  (7-27)

MinBt Log 2SizeY=MinCb Log 2SizeY  (7-28)

MaxTt Log 2SizeY=(slice_type==I)?5:6  (7-29)

MinTt Log 2SizeY=MinCb Log 2SizeY  (7-30)

MinQtSizeY=1<<MinQt Log 2SizeY  (7-31)

MaxBtSizeY=1<<MaxBt Log 2SizeY  (7-32)

MinBtSizeY=1<<MinBt Log 2SizeY  (7-33)

MaxTtSizeY=1<<MaxTt Log 2SizeY  (7-34)

MinTtSizeY=1<<MinTt Log 2SizeY  (7-35)

MaxMttDepth=(slice_type==I)?max_mtt_hierarchy_depth_intra_slices:max_mtt_hierarchy_depth_inter_slices  (7-36)

The dep_quant_enabled_flag is set equal to zero to specify thatdependent quantization is disabled. The dep_quant_enabled_flag is setequal to one to specify that dependent quantization is enabled. Thesign_data_hiding_enabled_flag is set equal to zero to specify that signbit hiding is disabled. The sign_data_hiding_enabled_flag is set equalto one to specify that sign bit hiding is enabled. Whensign_data_hiding_enabled_flag is not present, it is inferred to be equalto zero. The slice_boundary_treated_as_pic_boundary_flag is set equal toone to specify that each slice boundary of the slice is treated the sameas picture boundary in the decoding process. Theslice_boundary_treated_as_pic_boundary_flag equal to zero specifies thateach tile boundary may or may not be treated the same as pictureboundary in the decoding process. When not present, the value ofslice_boundary_treated_as_pic_boundary_flag is inferred to be equal toone. The offset_len_minus1 plus 1 specifies the length, in bits, of theentry_point_offset_minus1[i] syntax elements. The value ofoffset_len_minus shall be in the range of 0 to 31, inclusive. Theentry_point_offset_minus1[i] plus 1 specifies the i-th entry pointoffset in bytes, and is represented by offset_len_minus1 plus 1 bits.The slice data that follow the slice header consists of NumTilesInSlicesubsets, with subset index values ranging from 0 to NumTilesInSlice−1,inclusive. The first byte of the slice data is considered byte zero.When present, emulation prevention bytes that appear in the slice dataportion of the coded slice NAL unit are counted as part of the slicedata for purposes of subset identification.

Subset zero include bytes zero to entry_point_offset_minus1[0],inclusive, of the coded slice segment data, subset k, with k in therange of 1 to NumTilesInSlice−2, inclusive, includes bytes firstByte[k]to lastByte[k], inclusive, of the coded slice data with firstByte[k] andlastByte[k] defined as:

$\begin{matrix}{{{first}\; {{Byte}\lbrack\ k\rbrack}} = {\sum\limits_{n = 1}^{k}\; \left( {{{{entry}\_ {point}}_{-}offset_{-}{minus}\; {1\left\lbrack {n - 1} \right\rbrack}} + 1} \right)}} & \left( {7 - 37} \right) \\{{{last}\; {{Byte}\lbrack k\rbrack}} = {{{first}\; {{Byte}\lbrack k\rbrack}} + {entry_{-}point_{-}offset_{-}{minus}\; {1\lbrack k\rbrack}}}} & \left( {7 - 38} \right)\end{matrix}$

The last subset (with subset index equal to NumTilesInSlice−1) includesthe remaining bytes of the coded slice data. Each subset shall includeall coded bits of all CTUs in the slice that are within the same tile.

The general slice data semantics are as follows: The end_of_tile_one_bitshall be equal to one. For each tile, the variables LeftBoundaryPos,TopBoundaryPos, RightBoundaryPos and BotBoundaryPos are derived asfollows. If tile_boundary_treated_as_pic_boundary_flag is equal to true,the following applies:

tileColIdx=CurrTileIdx/(num_tile_columns_minus1+1)  (7-39)

tileRowIdx=CurrTileIdx % (num_tile_columns_minus1+1)  (7-40)

LeftBoundaryPos=ColBd[tileColIdx]<<Ctb Log 2SizeY  (7-41)

RightBoundaryPos=((ColBd[tileColIdx]+ColWidth[tileColIdx])<<Ctb Log2SizeY)−1  (7-42)

TopBoundaryPos=RowBd[tileRowIdx]<<Ctb Log 2SizeY  (7-43)

BotBoundaryPos=((RowBd[tileRowIdx]+RowHeight[tileRowIdx])<<Ctb Log2SizeY−1  (7-44)

Otherwise if slice_boundary_treated_as_pic_boundary_flag is equal totrue, the following applies:

sliceFirstTileColIdx=TileIdToIdx[top_left_tile_id]/(num_tile_columns_minus1+1)  (7-45)

sliceFirstTileRowIdx=TileIdToIdx[top_left_tile_id] %(num_tile_columns_minus1+1)   (7-46)

sliceLastTileColIdx=TileIdToIdx[bottom_right_tile_id]/(num_tile_columns_minus1+1)  (7-47)

sliceLastTileRowIdx=TileIdToIdx[bottom_right_tile_id] %(num_tile_columns_minus1+1)   (7-48)

LeftBoundaryPos=ColBd[sliceFirstTileColIdx]<<Ctb Log 2SizeY  (7-49)

RightBoundaryPos=((ColBd[sliceLastTileColIdx]+ColWidth[sliceLastTileColIdx])<<CtbLog 2SizeY)−1  (7-50)

TopBoundaryPos=RowBd[sliceFirstTileRowIdx]<<Ctb Log 2SizeY  (7-51)

BotBoundaryPos=((RowBd[sliceLastTileRowIdx]+RowHeight[sliceLastTileRowIdx])<<CtbLog 2SizeY)−1  (7-52)

Otherwise (slice_boundary_treated_as_pic_boundary_flag is equal toFALSE), the following applies:

LeftBoundaryPos=0  (7-53)

RightBoundaryPos=pic_width_in_luma_samples−1  (7-54)

TopBoundaryPos=0  (7-55)

BotBoundaryPos=pic_height_in_luma_samples−1  (7-56)

The derivation process for temporal luma motion vector prediction is asfollows. If yCb>>Ctb Log 2SizeY is equal to yColBr>>Ctb Log 2SizeY,yColBr is less than pic_height_in_luma_samples, and xColBr is less thanpic_width_in_luma_samples, the following applies:

The variable colCb specifies the luma coding block covering the modifiedlocation given by ((xCoBr>>3)<3, (yCoBr>>3)<3) inside the collocatedpicture specified by ColPic. The luma location (xColCb, yColCb) is setequal to the top-left sample of the collocated luma coding blockspecified by colCb relative to the top-left luma sample of thecollocated picture specified by CoPic. The derivation process forcollocated motion vectors is invoked with currCb, colCb, (xCoCb,yColCb), refIdxLX, and control parameter controlParaFlag set equal to 0as inputs, and the output is assigned to mvLXCol and availableFlagLXCol.If yCb>>Ctb Log 2SizeY is equal to yColBr>>Ctb Log 2SizeY, yColBr isless than or equal to BotBoundaryPos and xCoBr is less than or equal toRightBoundaryPos, the following applies. The variable colCb specifiesthe luma coding block covering the modified location given by(((xColBr>>3)<<3, (yCoBr>>3)<<3) inside the collocated picture specifiedby ColPic. The luma location (xColCb, yColCb) is set equal to thetop-left sample of the collocated luma coding block specified by colCbrelative to the top-left luma sample of the collocated picture specifiedby ColPic. The derivation process for collocated motion vectors isinvoked with currCb, coCb, (xCoCb, yCoCb), refIdxLX, and controlparameter controlParaFlag set equal to 0 as inputs, and the output isassigned to mvLXCol and availableFlagLXCol.

In some examples, the derivation process for temporal luma motion vectorprediction is as follows. If yCb>>Ctb Log 2SizeY is equal to yCoBr>>CtbLog 2SizeY, yColBr is less than pic_height_in_luma_samples and xColBr isless than pic_width_in_luma_samples, the following applies. The variablecolCb specifies the luma coding block covering the modified locationgiven by ((xColBr>>3)<<3, (yColBr>>3)<<3) inside the collocated picturespecified by ColPic. The luma location (xColCb,yCoCb) is set equal tothe top-left sample of the collocated luma coding block specified bycolCb relative to the top-left luma sample of the collocated picturespecified by ColPic. The derivation process for collocated motionvectors is invoked with currCb, colCb, (xColCb, yColCb), refIdxLX, andcontrol parameter controlParaFlag set equal to 0 as inputs, and theoutput is assigned to mvLXCol and availableFlagLXCol. If yCb>>Ctb Log2SizeY is equal to yCoBr>>Ctb Log 2SizeY, the following applies.xColCtr=Min(xColCtr, RightBoundaryPos) and yColCtr=Min(yColCtr,BotBoundaryPos). The variable colCb specifies the luma coding blockcovering the modified location given by ((xCoBr>>3)<<3, (yColBr>>3)<<3)inside the collocated picture specified by ColPic. The luma location(xColCb, yColCb) is set equal to the top-left sample of the collocatedluma coding block specified by colCb relative to the top-left lumasample of the collocated picture specified by CoPic. The derivationprocess for collocated motion vectors is invoked with currCb, colCb,(xColCb, yColCb), refIdxLX, and control parameter controlParaFlag setequal to 0 as inputs, and the output is assigned to mvLXCol andavailableFlagLXCol.

The luma sample interpolation process is as follows. The inputs to thisprocess are: a luma location in full-sample units (xIntL, yIntL); a lumalocation in fractional-sample units (xFracL, yFracL); and the lumareference sample array refPicLXL. The output of this process is apredicted luma sample value predSampleLXL. The variables shift1, shift2,shift3 are derived as follows. The variable shift1 is set equal toMin(4, BitDepthY−8) and the variable shift2 is set equal to 6 and thevariable shift3 is set equal to Max(2, 14−BitDepthY). The predicted lumasample value predSampleLXL is derived as follows. If both xFracLandyFracL are equal to 0, the value of predSampleLXL is derived as follows:

predSampleLXL=refPicLXL[xIntL][yIntL]<<shift3  (8-228)

Otherwise if xFracL is not equal to 0 and yFracL is equal to 0, thevalue of predSampleLXL is derived as follows:

predSampleLXL=(fL[xFracL,0]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−3)][yIntL]+fL[xFracL][1]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−2)][yIntL]+fL[xFracL][2]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−1)][yIntL]+fL[xFracL][3]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL)][yIntL]fL[xFracL][4]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+1)][yIntL]+fL[xFracL][5]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+2)][yIntL]+fL[xFracL][6]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+3)][yIntL]+fL[xFracL][7]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+4)][yIntL])>>shift1  (8-228)

Otherwise if xFracL is equal to 0 and yFracL is not equal to 0, thevalue of predSampleLXL is derived as follows:

predSampleLXL=(fL[yFracL,0]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL-3)]+fL[yFracL][1]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL-2)]+fL[yFracL][2]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL−1)]+fL[yFracL][3]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL)]+fL[yFracL][4]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+1)]+fL[yFracL][5]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+2)]+fL[yFracL][6]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+3)]+fL[yFracL][7]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+4)])>>shift1  (8-228)

Otherwise if xFracL is not equal to 0 and yFracL is not equal to 0, thevalue of predSampleLXL is derived as follows. The sample array temp[n]with n=0.7, is derived as follows:

yPosL=Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+n−3)  (8-228)

temp[n]=(fL[xFracL,0]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−3)][yPosL]+fL[xFracL][1]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL-2)][yPosL]+fL[xFracL][2]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL-1)][yPosL]+fL[xFracL][3]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL)][yPosL]+fL[xFracL][4]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+1)][yPosL]+fL[xFracL][5]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+2)][yPosL]+fL[xFracL][6]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+3)][yPosL]+fL[xFracL][7]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+4)][yPosL])>>shift1  (8-228)

The predicted luma sample value predSampleLXL is derived as follows:

predSampleLXL(fL[yFracL][0]*temp[0]+fL[yFracL][1]*temp[1]+fL[yFracL][2]*temp[2]+fL[yFracL][3]*temp[3]+fL[yFracL][4]*temp[4]+fL[yFracL][5]*temp[5]+fL[yFracL][6]*temp[6]+fL[yFracL][7]*temp[7])>>shift2  (8-228)

TABLE 5 Frac- tional interpolation filter coefficients sample fL[ p ]fL[ p ] fL[ p ] fL[ p ] fL[ p ] fL[ p ] fL[ p ] fL[ p ] position p [ 0 ][ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ]  1 0 1 −3 63 4 −2 1 0  2 −1 2−5 62 8 −3 1 0  3 −1 3 −8 60 13 −4 1 0  4 −1 4 −10 58 17 −5 1 0  5 −1 4−11 52 26 −8 3 −1  6 −1 3 −9 47 31 −10 4 −1  7 −1 4 −11 45 34 −10 4 −1 8 −1 4 −11 40 40 −11 4 −1  9 −1 4 −10 34 45 −11 4 −1 10 −1 4 −10 31 47−9 3 −1 11 −1 3 −8 26 52 −11 4 −1 12 0 1 −5 17 58 −10 4 −1 13 0 1 −4 1360 −8 3 −1 14 0 1 −3 8 62 −5 2 −1 15 0 1 −2 4 63 −3 1 0

The chroma sample interpolation process is as follows. Inputs to thisprocess are: a chroma location in full-sample units (xIntC, yIntC); achroma location in eighth fractional-sample units (xFracC, yFracC); andthe chroma reference sample array refPicLXC. Output of this process is apredicted chroma sample value predSampleLXC. The variables shift1,shift2, shift3, picWC and picHC are derived as follows. The variableshift1 is set equal to Min(4, BitDepthC−8), the variable shift2 is setequal to 6, and the variable shift3 is set equal to Max(2,14−BitDepthC). The variablel lPos, rPos, tPos and bPos are set asfollows:

lPos=LeftBoundaryPos/SubWidthC  (8-228)

rPos=(RightBoundaryPos+1)/SubWidthC  (8-228)

tPos=TopBoundaryPos/SubHeightC  (8-228)

bPos=(BotBoundaryPos+1)/SubHeightC  (8-228)

The predicted chorma sample value predSampleLXC is derived as follows.If both xFracC and yFracC are equal to 0, the value of predSampleLXC isderived as follows:

predSampleLXC=refPicLXC[xIntC][yIntC]<<shift3  (8-228)

Otherwise if xFracC is not equal to 0 and yFracC is equal to 0, thevalue of predSampleLXC is derived as follows:

predSampleLXC=(fC[xFracC][0]*refPicLXC[Clip3(lPos,rPos,xIntC−1)][yIntC]+fC[xFracC][1]*refPicLXC[Clip3(lPos,rPos,xIntC)][yIntC]+fC[xFracC][2]*refPicLXC[Clip3(lPos,rPos,xIntC+1)][yIntC]+fC[xFracC][3]*refPicLXC[Clip3(lPos,rPos,xIntC+2)][yIntC])>>shift1  (8-228)

Otherwise if xFracC is equal to 0 and yFracC is not equal to 0, thevalue of predSampleLXC is derived as follows:

redSampleLXC=(fC[yFracC][0]*refPicLXC[xlntC][Clip3(tPos,bPos,yIntC−1)]+fC[yFracC][1]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC)]+fC[yFracC][2]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC+1)]+fC[yFracC][3]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC+2)])>>shift1  (8-228)

Otherwise if xFracC is not equal to 0 and yFracC is not equal to 0, thevalue of predSampleLXC is derived as follows. The sample array temp[n]with n=0.3, is derived as follows:

yPosC=Clip3(tPos,bPos,yIntC+n−1)  (8-228)

temp[n]=(fC[xFracC][0]*refPicLXC[Clip3(lPos,rPos,xIntC−1)][yPosC]+fC[xFracC][1]*refPicLXC[Clip3(lPos,rPos,xIntC)][yPosC]+fC[xFracC][2]*refPicLXC[Clip3(lPos,rPos,xIntC+1)][yPosC]+fC[xFracC][3]*refPicLXC[Clip3(lPos,rPos,xIntC+2)][yPosC])>>shift1  (8-228)

The predicted chroma sample value predSampleLXC is derived as follows:

predSampleLXC=(fC[yFracC][0]*temp[0]+fC[yFracC][1]*temp[1]+fC[yFracC][2]*temp[2]+fC[yFracC][3]*temp[3])>>shift2  (8-228)

TABLE 6 Fractional sample interpolation filter coefficients position pfC[ p ]] 0 ] fC[ p ][ 1 ] fC[ p ][ 2 ] fC[ p ][ 3 ] 1 −1 63 2 0 2 −2 624 0 3 −2 60 7 −1 4 −2 58 10 −2 5 −3 57 12 −2 6 −4 56 14 −2 7 −4 55 15 −28 −4 54 16 −2 9 −5 53 18 −2 10 −6 52 20 −2 11 −6 49 24 −3 12 −6 46 28 −413 −5 44 29 −4 14 −4 42 30 −4 15 −4 39 33 −4 16 −4 36 36 −4 17 −4 33 39−4 18 −4 30 42 −4 19 −4 29 44 −5 20 −4 28 46 −6 21 −3 24 49 −6 22 −2 2052 −6 23 −2 18 53 −5 24 −2 16 54 −4 25 −2 15 55 −4 26 −2 14 56 −4 27 −212 57 −3 28 −2 10 58 −2 29 −1 7 60 −2 30 0 4 62 −2 31 0 2 63 −1

The Context-Based Adaptive Binary Arithmetic Coding (CABAC) parsingprocess for slice data is as follows. The initialization process isinvoked when starting the parsing of the CTU syntax and the CTU is thefirst CTU in a tile. Note that the start of the slice data is alsocovered by this sentence as each start of the slice data is the start ofa tile.

In another example, the CTB raster and tile scanning process is asfollows. The list ColWidth[i] for i ranging from 0 tonum_tile_columns_minus, inclusive, specifying the width of the i-th tilecolumn in units of CTBs, is derived as follows:

if( uniform_tile_spacing_flag )  for( i = 0; i <=num_tile_columns_minus1; i++ )   ColWidth[ i ] = ( ( i + 1) *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) − ( i *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) else {  ColWidth[num_tile_columns_minus1 ] = PicWidthInCtbsY    (6-1)  for( i = 0; i <num_tile_columns_minus1; i++) {   ColWidth[ i ] =tile_column_width_minus1[ i ] + 1   ColWidth[ num_tile_columns_minus1 ]−= ColWidth[ i ]  } }

The list RowHeight[j] for j ranging from 0 to num_tile_rows_minus1,inclusive, specifying the height of the j-th tile row in units of CTBs,is derived as follows:

if( uniform_tile_spacing_flag )  for( j = 0; j <= num_tile_rows_minus1;j++ )   RowHeight[ j ] = ( ( j + 1) * PicHeightInCtbsY ) / (num_tile_rows_minus1 + 1) −                  ( j * PicHeightInCtbsY ) /(num_tile_rows_minus1 + 1 ) else {  RowHeight[ num_tile_rows_minus1 ] =PicHeightInCtbsY (6-2)  for( j = 0; j < num_tile_rows_minus1; j++ ) {  RowHeight[ j ] = tile_row_height_minus1[ j ] + 1   RowHeight[num_tile_rows_minus1 ] −= RowHeight[ j ]  } }

The list ColBd[i] for i ranging from 0 to num_tile_columns_minus1+1,inclusive, specifying the location of the i-th tile column boundary inunits of CTBs, is derived as follows:

for(ColBd[0]=0,i=0;i<=num_tile_columns_minus1;i++)ColBd[i+1]=ColBd[i]+ColWidth[i]  (6-3)

The list RowBd[j] for j ranging from 0 to num_tile_rows_minus1+1,inclusive, specifying the location of the j-th tile row boundary inunits of CTBs, is derived as follows:

for(RowBd[0]=0,j=0;j<=num_tile_rows_minus;j++)RowBd[j+1]=RowBd[j]+RowHeight[j]  (6-4)

The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in CTB raster scan of a picture to a CTB address in tile scan,is derived as follows:

for( ctbAddrRs = 0; ctbAddrRs < PicSizeInCtbsY; ctbAddrRs++ ) {  tbX =ctbAddrRs % PicWidthInCtbsY  tbY = ctbAddrRs / PicWidthInCtbsY  for( i =0; i <= num_tile_columns_minus1; i++ )   if( tbX >= ColBd[ i ] )   tileX = i  for( j = 0; j <= num_tile_rows_minus1; j++ )         (6-5)  if( tbY >= RowBd[ j ] )    tileY = j  CtbAddrRsToTs[ ctbAddrRs ] = 0 for( i = 0; i < tileX; i++ )   CtbAddrRsToTs[ ctbAddrRs ] += RowHeight[tileY ] * ColWidth[ i ]  for( j = 0; j < tileY; j++ )   CtbAddrRsToTs[ctbAddrRs ] += PicWidthInCtbsY * RowHeight[ j ]   CtbAddrRsToTs[ctbAddrRs ] += ( tbY − RowBd[ tileY ] ) * ColWidth[ tileX ] + tbX −ColBd[ tileX ] }

The list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a CTB address in CTB raster scan of a picture,is derived as follows:

for(ctbAddrRs=0;ctbAddrRs<PicSizeInCtbsY;ctbAddrRs++)CtbAddrTsToRs[CtbAddrRsToTs[ctbAddrRs]]=ctbAddrRs  (6-6)

The list TileId[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a tile ID, is derived as follows:

for(j=0,tileIdx=0;j<=num_tile_rows_minus1;j++)for(i=0;i<=num_tile_columnsminus1;i++,tileIdx++)for(y=RowBd[j];y<RowBd[j+1];y++)for(x=ColBd[i];x<ColBd[i+1];x++)TileId[CtbAddrRsToTs[y*PicWidthnCtbsY+x]]=

tileIdx  (6-7)

The list NumCtusInTile[tileIdx] for tileIdx ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a tile indexto the number of CTUs in the tile, is derived as follows:

for(j=0,tileIdx=0;j<=num_tile_rows_minus1;j++)for(i=0;i<=num_tile_columns_minus1;i++,tileIdx++)NumCtusInTile[tileIdx]=ColWidth[i]RowHeight[j]  (6-8)

The set TileIdToIdx[tileId] for a set of NumTilesInPic tileId valuesspecifying the conversion from a tile ID to a tile index and the listFirstCtbAddrTs[tileIdx] for tileIdx ranging from 0 to NumTilesInPic−1,inclusive, specifying the conversion from a tile ID to the CTB addressin tile scan of the first CTB in the tile are derived as follows:

for( ctbAddrTs = 0, tileIdx = 0, tileStartFlag = 1; ctbAddrTs <PicSizeInCtbsY; ctbAddrTs++ ) {  if( tileStartFlag ) {   TileIdToIdx[TileId[ ctbAddrTs ] ] = tileIdx   FirstCtbAddrTs[ tileIdx ] = ctbAddrTs(6-9)   tileStartFlag = 0  }  tileEndFlag = ctbAddrTs = = PicSizeInCtbsY− | | TileId[ ctbAddrTs + 1 ] != TileId[ ctbAddrTs ]  if( tileEndFlag ){   tileIdx++   tileStartFlag = 1  } }

The values of ColumnWidthInLumaSamples[i], specifying the width of thei-th tile column in units of luma samples, are set equal toColWidth[i]<<Ctb Log 2SizeY for ranging from 0 tonum_tile_columns_minus1, inclusive. The values ofRowHeightnumaSamples[j], specifying the height of the j-th tile row inunits of luma samples, are set equal to RowHeight[ ]<<Ctb Log 2SizeY forj ranging from 0 to num_tile_rows_minus1, inclusive.

The Picture parameter set RBSP syntax is as follows.

TABLE 7 Descriptor pic_parameter_set_rbsp( ) { pps_pic_parameter_set_idue(v) pps_seq_parameter_set_id ue(v) transform_skip_enabled_flag u(1)single_tile_in_pic_flag u(1) if( !single_tile_in_pic_flag ) {num_tile_columns_minus1 ue(v) num_tile_rows_minus1 ue(v) }

if( !single_tile_in_pic_flag ) { uniform_tile_spacing_flag u(1) if(!uniform_tile_spacing_flag ) { for( i = 0; i < num_tile_columns_minus1;i++ ) tile_column_width_minus1[ i ] ue(v) for( i = 0; i <num_tile_rows_minus1; i++ ) tile_row_height_minus1[ i ] ue(v) }tile_boundary_treated_as_pic_boundary_flag u(1) if(tile_boundary_treated_as_pic_boundary_flag )loop_filter_across_tiles_enabled_flag u(1) } rbsp_trailing_bits( ) }

The slice header syntax is as follows:

TABLE 8 slice_header( ) { Descriptor slice_pic_parameter_set_id ue(v)first_slice_in_pic_flag u(1) single_tile_in_slice_flag u(1) if(!first_slice_in_pic_flag ) top_left_tile_id u(v) if(!single_tile_in_slice_flag ) bottom_right_tile_id u(v) slice_type ue(v)if ( slice_type != I )     log2_diff_ctu_max_bt_size ue(v)dep_quant_enabled_flag u(1) if( !dep_quant_enabled_flag )  sign_data_hiding_enabled_flag u(1) all_tiles_mcts_flag u(1) if(!tile_boundary_treated_as_pic_ boundary_flag && !all_tiles_mcts_flag )slice_boundary_treated_as_pic_boundary_flag if(!single_tile_in_slice_flag ) { offset_len_minus1 ue(v) for( i = 0; i <NumTilesInSlice − 1; i++ )     entry_point_offset_minus1[ i ] u(v)   }byte_alignment( ) }

The slice header semantics are as follows. When present, the value ofthe slice header syntax element slice_pic_parameter_set_id shall be thesame in all slice headers of a coded picture. Theslice_pic_parameter_set_id specifies the value ofpps_pic_parameter_set_id for the PPS in use. The value ofslice_pic_parameter_set_id shall be in the range of 0 to 63, inclusive.The first_slice_in_pic_flag is set equal to one to specify that theslice is the first slice of the picture in decoding order. Thefirst_slice_in_pic_flag is set equal to zero to specify that the sliceis not the first slice of the picture in decoding order. Thesingle_tile_in_slice_flag is set equal to one to specify that there isonly one tile in the slice. single_picture_in_pic_flag equal to 0specifies that there is more than one tile in the slice. Thetop_left_tile_id specifies the tile ID of the tile located at thetop-left corner of the slice. The length of top_left_tile_id is Ceil(Log2((num_tile_rows_minus1+1)*(num_tile_columns_minus1+1))) bits. The valueof top_left_tile_id shall not be equal to the value of top_left_tile_idof any other coded slice NAL unit of the same coded picture. When notpresent, the value of top_left_tile_id is inferred to be equal to zero.When there is more than one slice in a picture, the decoding order ofthe slices in the picture shall be in increasing value oftop_left_tile_id. The bottom_right_tile_id specifies the tile ID of thetile located at the bottom-right corner of the slice. The length ofbottom_right_tile_id is Ceil(Log2((num_tile_rows_minus1+1)*(num_tile_columns_minus+1))) bits. When notpresent, the value of bottom_right_tile_id is inferred to be equal totop_left_tile_id. The variables NumTileRowsInSlice,NumTileColumnsInSlice, and NumTilesInSlice are derived as follows:

deltaTileIdx=TileIdToIdx[bottom_right_tile_id]−TileIdToIdx[top_left_tile_id]NumTileRowsInSlice=(deltaTileIdx/(num_tile_columns_minus1+1))+1NumTileColumnsInSlice=(deltaTileIdx%(num_tile_columns_minus1+1))+1NumTilesInSlice=NumTileRowsInSlice*NumTileColumnsInSlice  (7-25)

The all_tiles_mcts_flag is set equal to one to specify that all tiles inthe slice are part of an MCTS, which only contains the tiles in theslice for the current access unit, and the MCTS boundaries (whichcollocate with the slice boundaries of the slice) are treated the sameas the picture boundaries. The all_tiles_mets_flag is set equal to zeroto specify that the above as specified by all_tiles_mcts_flag equal to 1may or may not apply. The slice_boundary_treated_as_pic_boundary_flag isset equal to one to specify that each slice boundary of the slice istreated the same as the picture boundary in the decoding process. Theslice_boudnary_treated_as_pic_boundary_flag is set equal to zero tospecify that each tile boundary may or may not be treated the same asthe picture boundary in the decoding process. When not present, thevalue of slice_boundary_treated_as_pic_boundary_flag is inferred to beequal to one. Each subset shall include all coded bits of all CTUs inthe slice that are within the same tile.

FIG. 7 is a schematic diagram of an example image 700 with a slicecontaining a single tile. For example, image 700 may be employed toimplement an image 600. Further, image 700 can be encoded in and decodedfrom a bitstream 500, for example by a codec system 200, an encoder 300,and/or a decoder 400. Further, the image 700 can be partitioned tosupport encoding and decoding according to method 100.

The image 700 can include a slice 721 and a tile 723, which may besubstantially similar to a slice 521 and/or 621 and a tile 523 and/or623, respectively. In some cases, a slice 721 may contain a single tile723. In some cases, an image 700 may contain a single tile 723. FIG. 7depicts both of these cases. The tile 723 may be further subdivided intoCTUs and coding blocks for encoding/decoding. This scenario may occurwhen a slice 721 and/or image 700 contains little visual data. Forexample, a slice 721 may contain a single tile 723 when the slice 721contains a large amount of white space and/or black space with little orno additional visual information (e.g., the slice contains a blindingspotlight or a black cave/building entrance). As another example, animage 700 may contain a single tile 723 when the entire image is whiteand/or black, for example during a fade between scenes. Such occurrencesare relatively common in video sequences. Slicing and tiling schemesprovide support for relatively complex computations for use incompressing high resolution images with significant detail. However,such complex computations employ significant input data and usesignificant processing resources at a decoder. Such computations may notprovide additional visual information for an image such as image 700 andmay require inputs that would reduce compression.

Accordingly, an encoder can use one or more flags to signal when ascenario as described with respect to image 700 occurs. A decoder canread such flags and omit corresponding computations, which reducescomputation resource usage at the decoder. As such computations areomitted, the related inputs can also be omitted from the bitstream,which increases compression and coding efficiency. Examples of data thatcan be omitted includes slice 721 boundaries (as there is only one slice721 when there is only one tile 723 in the image 700), tile IDs, tilecolumn data, tile row data, tile spacing data, and/or tile entry pointoffsets. Computations that can be omitted include determining a bottomright tile ID as part of determining a slice 721 boundary, determiningtile 723 entry point offsets, determining tile columns and rows,determining the number of tiles, determining tile spacing, etc. In oneexample, a single_tile_in_slice_flag can be set to indicate that thereis only one tile 723 in a slice 721. The single_tile_in_slice_flag canbe signaled in a slice header, such as slice header 514, associated withthe slice 721. In another example, a single_tile_in_pic_flag can be setto indicate that there is only one tile 723 in an image 700. Thesingle_tile_in_pic_flag can be signaled in a PPS, such as PPS 512,associated with the image 700.

FIG. 8 is a schematic diagram of an example video coding device 800. Thevideo coding device 800 is suitable for implementing the disclosedexamples/embodiments as described herein. The video coding device 800comprises downstream ports 820, upstream ports 850, and/or transceiverunits (Tx/Rx) 810, including transmitters and/or receivers forcommunicating data upstream and/or downstream over a network. The videocoding device 800 also includes a processor 830 including a logic unitand/or central processing unit (CPU) to process the data and a memory832 for storing the data. The video coding device 800 may also compriseelectrical, optical-to-electrical (OE) components, electrical-to-optical(EO) components, and/or wireless communication components coupled to theupstream ports 850 and/or downstream ports 820 for communication of datavia electrical, optical, or wireless communication networks. The videocoding device 800 may also include input and/or output (I/O) devices 860for communicating data to and from a user. The/O devices 860 may includeoutput devices such as a display for displaying video data, speakers foroutputting audio data, etc. The I/O devices 860 may also include inputdevices, such as a keyboard, mouse, trackball, etc., and/orcorresponding interfaces for interacting with such output devices.

The processor 830 is implemented by hardware and software. The processor830 may be implemented as one or more CPU chips, cores (e.g., as amulti-core processor), field-programmable gate arrays (FPGAs),application specific integrated circuits (ASICs), and digital signalprocessors (DSPs). The processor 830 is in communication with thedownstream ports 820, Tx/Rx 810, upstream ports 850, and memory 832. Theprocessor 830 comprises a coding module 814. The coding module 814implements the disclosed embodiments described above, such as methods100, 900, and 1000, which may employ a bitstream 500, an image 600,and/or an image 700. The coding module 814 may also implement any othermethod/mechanism described herein. Further, the coding module 814 mayimplement a codec system 200, an encoder 300, and/or a decoder 400. Forexample, the coding module 814 can partition an image into slices,slices into tiles, tiles into CTUs, CTUs into blocks, and encode theblocks when acting as an encoder. Further, the coding module 814 cansignal, via a flag in a bitstream, when an image and/or a slice containsa single tile. In addition, when acting as a decoder, the coding module814 can determine when an image and/or a slice contains a single tile byreading such flags from the bitstream. This allows the decoder to omitvarious computations related to a multi-tile environment, whichincreases compression and coding efficiency while decreasing computationtime at the decoder. As such, the coding module 814 causes the videocoding device 800 to provide additional functionality and/or codingefficiency when partitioning and coding video data. As such, the codingmodule 814 improves the functionality of the video coding device 800 aswell as addresses problems that are specific to the video coding arts.Further, the coding module 814 effects a transformation of the videocoding device 800 to a different state. Alternatively, the coding module814 can be implemented as instructions stored in the memory 832 andexecuted by the processor 830 (e.g., as a computer program productstored on a non-transitory medium).

The memory 832 comprises one or more memory types such as disks, tapedrives, solid-state drives, read only memory (ROM), random access memory(RAM), flash memory, ternary content-addressable memory (TCAM), staticrandom-access memory (SRAM), etc. The memory 832 may be used as anover-flow data storage device, to store programs when such programs areselected for execution, and to store instructions and data that are readduring program execution.

FIG. 9 is a flowchart of an example method 900 of encoding an image,such as image 600 and/or 700, with a slice containing a single tile intoa bitstream, such as bitstream 500. Method 900 may be employed by anencoder, such as a codec system 200, an encoder 300, and/or a videocoding device 800 when performing method 100.

Method 900 may begin when an encoder receives a video sequence includinga plurality of images and determines to encode that video sequence intoa bitstream, for example based on user input. The video sequence ispartitioned into pictures/images/frames for further partitioning priorto encoding. At step 901, a first image is partitioned into one or moreslices. The slice(s) are partitioned into one or more tiles. The tilesare partitioned into one or more CTUs. The CTUs are further partitionedinto one or more coding blocks.

At step 903, the encoder determines that a first slice in the firstimage contains a single tile after partitioning. The encoder can thenencode a first flag into a bitstream to indicate that the first slicecontains the single tile. For example, the first flag can be encoded ina slice header associated with the first slice. As a specific example,the first flag may be a single_tile_in_slice_flag set to one to indicatethat there is only one tile in the first slice. The encoder may alsoomit certain items from the bitstream when the first flag is set. Forexample, the encoder may omit a bottom right tile ID for the first slicefrom the bitstream based on the determination that the first slicecontains the single tile. As another example, the encoder may omit entrypoint offsets associated with the tiles for the first slice from thebitstream based on the determination that the first slice contains thesingle tile.

At optional step 905, the encoder may determine that the first image,which contains the first slice, also contains a single tile afterpartitioning. The encoder can then encode a second flag into thebitstream to indicate that the first image contains the single tile. Forexample, the second flag can be encoded in a PPS associated with thefirst image. As a specific example, the second flag may be asingle_tile_in_pic_flag set to one to indicate that there is only onetile in the first image. The encoder may also omit certain items fromthe bitstream when the second flag is set. For example, the encoder mayomit data related to the columns and rows of tiles in the first imagewhen the second flag is set.

At step 907, the encoder encodes the first image, the first slice, thesingle tile, CTUs, and coding block(s) into the bitstream. The encodercan then transmit the bitstream containing the first flag and/or thesecond flag to support decoding the first slice and/or the first image.

FIG. 10 is a flowchart of an example method 1000 of decoding an image,such as an image 600 and/or 700, with a slice containing a single tilefrom a bitstream, such as bitstream 500. Method 1000 may be employed bya decoder, such as a codec system 200, a decoder 400, and/or a videocoding device 800 when performing method 100.

Method 1000 may begin when a decoder begins receiving a bitstream ofcoded data representing a video sequence, for example as a result ofmethod 900. At step 1001, a bitstream is received at a decoder. Thebitstream includes image data divided into one or more slices, which arefurther divided into one or more tiles. The tile(s) are further dividedinto CTUs, which are divided into coding blocks.

At step 1003, the decoder determines that a first slice in the imagedata contains a single tile based on a first flag. For example, thefirst flag can be obtained from a slice header associated with the firstslice. As a specific example, the first flag may be asingle_tile_in_slice_flag set to one to indicate that there is only onetile in the first slice. The decoder may omit certain processes when thefirst flag is set. For example, a search for a bottom right tile ID forthe first slice can be omitted during decoding based on thedetermination that the first slice contains the single tile. As anotherexample, a search for entry point offsets associated with the tiles forthe first slice may also be omitted based on the determination that thefirst slice contains the single tile.

At step 1005, the decoder may optionally also determine that a firstpicture in the image data contains the single tile based on a secondflag. For example, the second flag can be encoded in a PPS associatedwith the first picture. As a specific example, the second flag may be asingle_tile_in_pic_flag set to one to indicate that there is only onetile in the first picture. The decoder may omit certain processes whenthe second flag is set. For example, the decoder may omit processesrelated to determining tile rows and tile columns for the first picturewhen the second flag is set and based on the determination that thefirst picture contains the single tile.

At step 1007, the decoder can decode the first slice to generate areconstructed image. Further, the first slice may be decoded as part ofdecoding the first picture to generate the reconstructed image. Thedecoder can also forward the reconstructed image toward a display aspart of a reconstructed video sequence at step 1009.

FIG. 11 is a schematic diagram of an example system 1100 for coding animage, such as an image 600 and/or 700, containing a single slice and/ortile in a bitstream, such as bitstream 500. System 1100 may beimplemented by an encoder and a decoder such as a codec system 200, anencoder 300, a decoder 400, and/or a video coding device 800. Further,system 1100 may be employed when implementing method 100, 900, and/or1000.

The system 1100 includes a video encoder 1102. The video encoder 1102comprises a partitioning module 1101 for partitioning a first image intoone or more slices and one or more tiles. The video encoder 1102 furthercomprises a determining module 1103 for determining that a first slicecontains a single tile after partitioning. The video encoder 1102further comprises an encoding module 1105 for encoding a first flag toindicate that the first slice contains the single tile, and encoding thefirst slice into a bitstream. The video encoder 1102 further comprises atransmitting module 1107 for transmitting the bitstream containing thefirst flag to support decoding the first slice. The video encoder 1102may be further configured to perform any of the steps of method 900.

The system 1100 also includes a video decoder 1110. The video decoder1110 comprises a receiving module 1111 for receiving a bitstreamincluding image data divided into one or more slices and one or moretiles. The video decoder 1110 further comprises a determining module1113 for determining that a first slice contains a single tile based ona first flag. The video decoder 1110 further comprises a decoding module1115 for decoding the first slice to generate a reconstructed image. Thevideo decoder 1110 may be further configured to perform any of the stepsof method 1000.

A first component is directly coupled to a second component when thereare no intervening components, except for a line, a trace, or anothermedium between the first component and the second component. The firstcomponent is indirectly coupled to the second component when there areintervening components other than a line, a trace, or another mediumbetween the first component and the second component. The term “coupled”and its variants include both directly coupled and indirectly coupled.The use of the term “about” means a range including 10% of thesubsequent number unless otherwise stated.

It should also be understood that the steps of the exemplary methods setforth herein are not necessarily required to be performed in the orderdescribed, and the order of the steps of such methods should beunderstood to be merely exemplary. Likewise, additional steps may beincluded in such methods, and certain steps may be omitted or combined,in methods consistent with various embodiments of the presentdisclosure.

While several embodiments have been provided in the present disclosure,it may be understood that the disclosed systems and methods might beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, components, techniques, ormethods without departing from the scope of the present disclosure.Other examples of changes, substitutions, and alterations areascertainable by one skilled in the art and may be made withoutdeparting from the spirit and scope disclosed herein.

What is claimed is:
 1. A method implemented in a decoder, the methodcomprising: receiving, by a receiver of the decoder, a bitstreamincluding image data divided into one or more slices, wherein the one ormore slices are further divided into one or more tiles; determining, bya processor of the decoder, that a first slice contains a single tilebased on a first flag; and decoding, by the processor, the first sliceto generate a reconstructed image.
 2. The method of claim 1, wherein thefirst flag is a single_tile_in_slice_flag set to one to indicate thatthere is only one tile in the first slice.
 3. The method of claim 1,wherein the first flag is coded in a slice header associated with thefirst slice.
 4. The method of claim 1, wherein decoding the first sliceincludes omitting a search for a bottom right tile identifier (ID) forthe first slice based on the determination that the first slice containsthe single tile.
 5. The method of claim 1, wherein decoding the firstslice includes omitting a search for entry point offsets associated withtiles for the first slice based on the determination that the firstslice contains the single tile.
 6. The method of claim 1, furthercomprising determining, by the processor, that a first picture containsthe single tile based on a second flag.
 7. The method of claim 6,wherein the second flag is a single_tile_in_pic_flag set in a pictureparameter set associated with the first picture.
 8. The method of claim6, wherein decoding the first slice is performed as part of decoding thefirst picture to generate the reconstructed image, and wherein decodingthe first picture includes omitting a determination of tile rows andtile columns for the first picture based on the determination that thefirst picture contains the single tile.
 9. The method of claim 1,further comprising forwarding, by the processor, the reconstructed imagetoward a display as part of a reconstructed video sequence.
 10. A methodimplemented in an encoder, the method comprising: partitioning, by aprocessor of the encoder, a first image into one or more slices, whereinthe one or more slices are further partitioned into one or more tiles;determining, by the processor, that a first slice of the first imagecontains a single tile after partitioning; encoding, by the processor, afirst flag to indicate that the first slice contains the single tile;encoding, by the processor, the first slice into a bitstream; andtransmitting, by a transmitter of the encoder, the bitstream containingthe first flag to support decoding the first slice.
 11. The method ofclaim 10, wherein the first flag is a single_tile_in_slice_flag set toone to indicate that there is only one tile in the first slice.
 12. Themethod of claim 10, wherein the first flag is encoded in a slice headerassociated with the first slice.
 13. The method of claim 10, wherein abottom right tile identifier (ID) for the first slice is omitted fromthe bitstream based on the determination that the first slice containsthe single tile.
 14. The method of claim 10, wherein entry point offsetsassociated with tiles for the first slice are omitted from the bitstreambased on the determination that the first slice contains the singletile.
 15. The method of claim 10, further comprising: determining, bythe processor, that the first image contains the single tile afterpartitioning; and encoding, by the processor, a single_tile_in_pic_flagin a picture parameter set associated with the first image to indicatethat the first image contains the single tile.
 16. A video coding devicecomprising: a receiver configured to receive a bitstream including imagedata divided into one or more slices, wherein the one or more slices arefurther divided into one or more tiles; and a processor configured to:determine that a first slice contains a single tile based on a firstflag; and decode the first slice to generate a reconstructed image. 17.The video coding device of claim 16, wherein the first flag is asingle_tile_in_slice_flag set to one to indicate that there is only onetile in the first slice.
 18. The video coding device of claim 16,wherein the first flag is coded in a slice header associated with thefirst slice.
 19. The video coding device of claim 16, wherein decodingthe first slice includes omitting a search for a bottom right tileidentifier (ID) for the first slice based on the determination that thefirst slice contains the single tile.
 20. The video coding device ofclaim 16, wherein decoding the first slice includes omitting a searchfor entry point offsets associated with tiles for the first slice basedon the determination that the first slice contains the single tile.